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.
5
1
4
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.)
Aug 5, 2019 · 2:56 AM UTC
1

