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
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.

Aug 3, 2019 · 10:20 PM UTC

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
Happens to me all the time.
Replying to @davidbaron
You lost me at the 3rd command 😵git add -p Git commit (--amend when I messed up) Everything else is just black magic and I will never understand it
Replying to @davidbaron
You can just `git rebase --continue` in both cases without ammending and git will do the right thing. In edit mode, it will amend the commit. In conflict resolution, it will not touch he previous commit.
Replying to @davidbaron
I've had that happen a few times. I think I usually don't do edits in the same rebase where I'm shuffling patches around, because I try to focus on one thing at a time. Doing less in each rebase also means you can just do rebase --abort and bail out without losing much.
1
2
Replying to @davidbaron
It is one of several Git UX pitfalls, I'd say... But importantly, your work shouldn't truly be lost, as `git reflog` should let you get back to a previous history.
Replying to @davidbaron
I think I sort of knew this but had never explicitly realized it. In general, ohshitgit.com/ has saved me a couple of times. Also:
Nicholas Nethercote @nnethercote
14 May 2019
With git, modifying patches in the middle of a patch stack (i.e. during a `git rebase -i`) feels like a temporary, error-prone situation that should be resolved ASAP. With Mercurial (using either mq or evolve) being in the middle of a patch stack feels normal and safe.
1
3
Replying to @davidbaron
git is an immutable object store with explicit garbage collection, so it's relatively hard to actually lose data if it's been committed. That said, yes, this is a known footgun (or at least known to me, because I've done it); git has no shortage of them.
Replying to @davidbaron
I have a long pointed out that the overriding design aesthetic of git seems to be maximizing surprise. Losing code is just one important aspect of that.
2
1
5
Replying to @davidbaron
Or you could switch back to hg 😈, but try evolve 😉
Load more