That said, hats off to the author for tracking down the problem. Regardless of workflow flaws, the behavior he observed is a bug, and I'm glad it's fixed.
git fetch
git rebase origin/master
git pull
git pull --rebase
git checkout master # because it always matches upstream
git pull # this will always fast-forward
git merge foo
git push
Didn't know about `git pull --rebase`. Thanks for that.
With `git pull`, it is all done in one operation.
Of course, if you've already reviewed the code or are pulling from your own remote repository then `git pull` is likely fine.
1. I might choose not to merge. The upstream code may be bad, or it may not be ready for a merge. I may need to do some more work to prepare my own code to merge.
2. I might wish to perform a fast-forward merge (if one is possible).
3. I might wish to force a non-fast-forward merge (if a fast-forward is possible). This is often a good idea, as it helps keep groups of commits related to a particular feature isolated.
4. I might wish to rebase.
The reason this happens is because git uses directed graphs and there is no link between the point at which you diverged from master and the other changes came in. The merge commit creates this. Unfortunately, it looks like you just committed everything that changed on both branches and the history can be difficult to track and/or confusing.
Fetch then merge will make the history more clear, but you still create a merge commit that will include all of the file changes (correct me if I am wrong here). git pull --rebase will take your changes out of the equation, pull in the new history and then replay them against the updated master branch. This is nice because your commit will only include (at this point) any merge conflicts resulting from your changes.
For a better explanation, with diagrams, see http://progit.org/book/ch3-6.html
I don't think this is really true. You'll just introduce a single merge commit on top of both your commits and the other person's. Yes, if you diff that merge against your own work, you'll see all the work that other people committed, but I think it's fairly well understood that a merge commit is just that - you merging your changes with other changes.
It can be a bit tricky to read the log when merge commits are involved, but try the --graph option or a graphical log tool.
After you do a fetch you can go on to do a merge just as though you did a git pull, but if you break down the steps then you now have the option to do a rebase or other operation as you see fit.
git pull --rebase
But, in any case doing the fetch would have shown that the file was not modified in the fetched tree, and it would have gone ahead and overwritten my changes (without even listing in the merge log that the file was changed).
FWIW, I agree that fetch + (merge | rebase) is in general the best way to go, but I think there is a case when you a pulling in a simple fix from head where doing a pull is legitimate.
After all the documentation says this is a safe operation:
"If any of the remote changes overlap with local uncommitted changes, the merge will be automatically cancelled and the work tree untouched" (from git pull --help).
If this isn't meant to be considered a safe operation git pull should abort if there are any changes to the working directory.
You're losing history that way: If the merge doesn't actually work, then you've got a screwed up file and no way to roll it back.
It's one of the great strengths of git that you can commit files even if someone else has changed them. It's a bad idea to merge when you have anything significant checked out (I'll leave temporary debugging changes checked out, or very small changes, but that's it). Heck, it's a good idea to check in every few hours, to track changes your making.