Jeff King <peff@xxxxxxxx> 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" 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html