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.
3
2
6
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.
1
1
1
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.
1
4
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".
2
1
1
3
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.

Aug 3, 2019 · 10:20 PM UTC

5
1
4
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.
11
1
5
(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.)
4
Replying to @davidbaron
I get you're annoyed but 1) it's not magic, it did what you told it to. 2) your work is not lost, but recovering it can be tedious. Practical advice: don't use amend when rebasing. Commit your edit changes as a new commit, and then do a 2nd rebase to squash them.
1
If that's the best way, then why does git's interactive rebase explicitly tell you to use 'git commit --amend'? (Advice I've gotten from others says that in recent git versions the best way is just to 'git add' and 'git rebase --continue', and it will implicitly amend.)
1
more replies
Replying to @davidbaron
Pretty sure `git reset --soft HEAD@{1} && git rebase --continue` gets you back on track?
1
Replying to @davidbaron
For the lost commit message, you could dig it out from reflog. To get back the original prior commit, you could do a rebase to edit the commit prior to that, cherry-pick the old commit from the reflog, then rebase --continue to turn the merged commit into the residue.
1
Replying to @davidbaron
Yeah I’ve definitely amended in a rebase. It’s frustrating. Typically I realise when git status or rebase —continue says something surprising but then it’s a —abort and repeat. I try to avoid spending time in edit mode by using multiple branches, then fix history for one push
1