Anyway, "git pull --rebase" is your friend. (And so is "git push --force". git pull will DTRT on the other end, so this shouldn't mess anyone else up.)
'--force' overrides this check, pushing anyways, effectively losing (possibly multiple) commits on the server. it should only be used if you were forced to change your history somehow (removing files with a password in it, rewinding work in an emergency), it should almost never be used and there should be a really good reason for it. i've used it maybe a dozen times last year of the thousands of pushes i've done.
Wait, what? I thought you were supposed to avoid "push --force" when pushing to a public repo?
My manpages still seem to warn against using both commands, but I'm locally running on a version dated 2/09/2009 (I have a cronjob at work that pulls down the latest version of git and compiles it daily).
[edit] Maybe by 'do the right thing' he means that it won't overwrite their local history (i.e. the pull/merge will fail because the histories are different)
Whenever you're rebasing, you should make sure you understand how git works and what the consequences are.
personally, i use a combination - i tend to rebase when it's only a couple of commits and i merge when there are dozens of commits off, whichever is easier/cleaner. if there are likely going to be conflicts to resolve, rebase is often a bit more difficult, and people tend to have a harder time understanding rebase conceptually so i tend not to encourage it's use to beginners. however, it's interesting to see how each person subtly differently sees how the world of VCS should be, and how Git makes it relatively easy to have such different workflows.
