Jeff King <> writes:

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

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"


>   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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to