Re: [PATCH] commit: correct advice about aborting a cherry-pick
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 29, 2013, 15:15 UTC
- Message-ID
- <7vy58p1joy.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20130726224359.GA3928@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 32 quoted lines
> 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"
True.
Show 8 quoted lines
> 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.