Re: [PATCH] commit: correct advice about aborting a cherry-pick

Jeff King [off-list ref] writes:

On Fri, Jul 26, 2013 at 05:40:36PM -0400, Jeff King wrote:

quoted

quoted

Jeff King wrote:

quoted

Your patch is just swapping out "git reset" for "cherry-pick --abort",
so I think that is a good improvement in the meantime.

Um, wasn't the idea of the original message that you can run "git
reset" and then "git cherry-pick --continue"?

Maybe. :)

I missed that subtlety. Of my "three things you would want to do", that
means it was _trying_ say number 2, how to skip, rather than 3, how to
abort. If that is the case, then it should probably explain the sequence
of steps as "reset and then --continue" to make it more clear.

I.e., a patch is needed, but Ram's is going in the opposite direction.

I played around a bit with the test cases that Ram showed. It seems like
the advice needed is different depending on whether you are in a single
or multi-commit cherry-pick.

So if we hit an empty commit and you want to:

  1. Make an empty commit, then always run "git commit --allow-empty".

  2. Skip this commit, then if:

     a. this is a single commit cherry-pick, you run "git reset" (and
        nothing more, the cherry pick is finished; running "cherry-pick
        --continue" will yield an error).

Yes, the single-replay mode never required "cherry-pick --continue"
to clean sequencer cruft when discarding a failed cherry-pick, so it
is a natural consequence of a conscious design decision that
"cherry-pick --continue" will say "you are not running a
cherry-pick", exactly because you no longer are.

     b. this is a multi-commit cherry-pick, you run "git reset",
        followed by "git cherry-pick --continue"

True.

  3. Abort the commit, run "git cherry-pick --abort"

Let's assume that the instructions we want to give the user are how to
do options 1 and 2. I do not mind omitting 3, as it should be reasonably
obvious that "cherry-pick --abort" is always good way to abort.

So we give good instructions for the single-commit case, but bad
instructions for the multi-commit case.

Yeah, that matches what I thought.  It appears that when we did a
shoddy job when teaching commit to give this advice-message and only
considered a single-pick mode, perhaps because multi-replay mode was
relatively new back then.

I think instead we would want to leave the single-commit case alone, and
for the multi-commit case add "...and then cherry-pick --continue". That
message is generated from within git-commit, though; I guess it would
need to learn about the difference between single/multi cherry-picks.

Sounds very sensible.