Mercurial has the same “You can’t merge upstream changes into your local, uncommitted modifications” issue, and it’s also annoying as hell. I have yet to find a workflow that doesn’t piss me off. If git offered one, I’d almost certainly switch.

Stashing is not a great solution, either – unless un-stashing lets you do a nice 3-way merge – with all the same flexibility as a normal merge. Mercurial’s equivalent (shelve) sucks, because you end up running some external tool like patch – which leaves little unapplied patches around when a patch fails, instead of the traditional merge – which lets you see both versions of the code.

I’m not too inspired to report this stuff to the Git developers, because my biggest gripes would require major changes to address (like renaming core commands). There’s no way they’d be receptive to that. Like I said, what I think Git’s UI needs is a revolutionary, not an evolutionary change.

@Dave: Your point is taken about being confident about the merge. But I like the Perforce model here (can’t remember if CVS and SVN do this too), where it prompts you for each file that has conflicting changes, and asks if you want to merge right now or not. If you get cold feed about it, you can always decline to do the merge, then do the stash+apply thing manually. But going ahead with the merge (especially if the changes don’t have conflicts) is nearly always what I want.

Good suggestion about git-mergetool — I should use that instead.

One reason is that this way you can confidently abort the merge. Git needs some state to which it can reset your working directory if you decide that the pull or the merging from the pull was a big mistake. You could make an argument that git ought to be able to do the equivalent of a “git stash” for you when merging, then apply the changes, and pop the stash with merging for you automatically. But it doesn’t do that. And I think that might actually be more confusing to some people, so I’m not sure it’s the right thing to do. My preference is almost always to fetch and then perform the merge or rebase as a separate step anyway.

As for the individual file merging, you should check out git-mergetool. It will pop you into a three way vimdiff (or whatever your preferred tool is) and then mark the file as resolved when you are done editing it. I find this much easier than actually figuring out which files are conflicting and editing them directly by hand, then resolving them by hand.

I agree about checkout and reset. They are too overloaded and the reset flavors are difficult to remember. This is probably one of the worst parts of the UI, especially since these commands can be so destructive.

I think git checkout is ok to overwrite the file, it’s what its supposed to do (it’s the “svn revert” for Git, “svn revert” don’t ask for your permission either), but I don’t see why a merge couldn’t be performed when the working copy is dirty, that would be helpful.

About the merge conflict, I think its similar to svn too, you have to mark your conflicted files “resolved” before committing (in Git you do a git add). The error message can be a little better though. About checking out a file that’s not merged yet, I’m not sure =)

I have trouble remembering what the different flavors of reset do.

You should try to report all this stuff to the Git developers, they are very receptive and very concerned about usability (Git has made *huge* improvements to the usability).

You can also fill the Git Survey 2009 too to express yourself =)
http://www.survs.com/survey?id=2PIMZGU0&channel=Q0EKJ3NF54