Re: [RFC/PATCH 0/7] some sequencer loose ends (Re: Fix revert --abort on Windows)

Jonathan Nieder wrote:

[... rambling cover letter snipped ...]

Let's try that again. :)

Current git has a somewhat odd behavior when cherry-picking multiple commits and running into a conflict in the _last_ commit of the series. Imagine the following sequence of operations:

 1. git cherry-pick simplething simplethingtwo complexthing
 2. CONFLICT.
 3. git cherry-pick --abort

It would be most consistent for the entire cherry-pick sequence to be rolled back, so the user can come up with some other sequence of commits to try. After all, that's what happens if a conflict is encountered applying simplethingtwo and the user asks to abort.

Instead, by the time complexthing is being applied, git has forgotten about the multi-pick sequence entirely. And the --abort does not even warn about this weird state --- it just cancels complexthing and leaves the earlier commits applied.

This is an edge case, but I think it's worth fixing. Patch 5/7 does so.

In the same vein, now imagine a different sequence of operations:

 1. git cherry-pick simplething complexthing morecommits...
 2. CONFLICT.
 3. git reset --merge
 4. git cherry-pick --continue

It would be sensible for this to remove the conflicted patch and go on with the remaining ones, right? But instead, "git reset" automagically removes the sequencer state, so you can't even use git cherry-pick --abort any more. Well, you can, if you say the magic words "mv .git/sequencer-old .git/sequencer", but nobody actually tells you that.

How did we ever let this in? "git reset" already has well defined semantics that have nothing to do with this. Patches 6/7 and 7/7 would help us forget this UI mistake (and I believe it was a mistake) ever happened.

Patch 2 makes cherry-pick --continue behave a little more like rebase --continue, for people who like to learn by analogy.

Patches 1 and 3 are just code style things.

Patch 4 is the basic building block that makes patch 5 possible: it teaches "git cherry-pick" to treat picks of a single commit named on the command line differently from the more complex multi-picks requested with general rev-list arguments. Single-pick is all that git cherry-pick originally supported, and in some details it has to differ from multi-pick (for example, "git commit" after resolving conflicts after a conflicted single-pick needs to be enough to clear the state). As a side-benefit, we get the ability to do a single-pick in the middle of a multi-pick, which is kind of cool and handy from time to time.

I am interested in sanity checking of the patches and testing. It would be pleasant to find comments like "yeah, that looks good" or "what are you thinking?! I ran into the following bug" arriving in my inbox.

Incidentally, I'd like to apologize about not protesting more about these things (and even having suggested some of them) as they happened. Instead of exercising careful oversight over the sanity of patches that passed through my mailbox, I had some strange idea of using the Socratic method to help others learn to explore the design space and sanity-check findings themselves...

Thanks for reading.

Ciao, Jonathan