So for a long time I did my mozilla development using Mercurial (hg) and patch queues (mq). I've recently switched to using git instead. My mercurial workflow was a bit odd, but it had the advantage that I never lost my work and had to rewrite it. Never.

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.