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

[Jeff King <peff@peff.net>]

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

> > Jeff King wrote:
> > 
> > > 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).

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

  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. Ram's patch suggests --abort
instead of reset, which is the same for the single-commit case, but
suggests 3 instead of 2 for the multi-patch.

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.

-Peff