Since I've started using git I've lost work and had to rewrite it twice. Both times I ended up with two commits merged together that should have been separate. The second time was just now, and I realized what I did.

My work generally involves developing series of patches meant to be on top of each other. With git, this involves a lot of "git rebase -i" (interactive rebase). The problem I hit is the differences between interactive rebase's "edit" mode and rebase's conflict resolution mode.

I do much more of the "edit" mode than the conflict resolution mode. In edit mode, you edit the files, "git add" them, "git commit --amend", and then "git rebase --continue". But in conflict resolution mode, you edit the files, "git add" them, and "git rebase --continue".

If you mess up in conflict resolution mode and type "git commit --amend" (the one difference from edit mode), what happens? The patch you're resolving conflicts in gets magically merged into the patch below it. Two changes, tangled together. One commit message lost.

Is this a well known problem? Do other people hit this a lot? Is it a well known "be really careful not to do this, or you'll lose your work"? Because not losing work is one of the core values of version control. And I'm *this* close to switching back to hg.

(I should note that most of the time in an interactive rebase I type "git commit --amend --no-edit" because I know I don't want to edit the commit message; that also means I don't see the UI that might have given me a hint that stuff was going to go wrong.)

That doesn't work if you're developing a series of changes that are supposed to make sense separately.

I can explain with links to examples when I'm back at my computer