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

So both the layout and DOM teams at Mozilla have a strong culture of producing small patches where each step compiles. This makes code review of large changes much easier, and also is useful for bisection when debugging regressions. (Other teams too, but probably less strongly.)

A relatively simple example is hg.mozilla.org/integration/a… . This was easier to code review as four separate patches than one. (#4 depends on #3 and #1. #3 depends on #2.) With more complex changes, the value goes up.

So I might write a series of six patches (probably compiling each one) before doing any testing. Then I hit a test failure and realize it's a bug in patch #2. This is before posting anything for code review. So I want the fix merged into patch #2. rebase -i.