Junio C Hamano wrote: > If we want to reach this point eventually, given that --reset was not in > any released version, and also given that we are deep in pre-release > phase, we probably should either just apply the first one (and perhaps > this one) from the series immediately before 1.7.8 final, or delay the > final and swallow the entire series. Makes sense. > I am not quite convinced that quit is *that* superiour over reset > though. The description in 1/3 "has a confusing name" does not say why it > is confusing, either, to help readers agree with the conclusion. Ok, a few words about this. I should say that I am not deeply attached to --quit. If some other word for "abandon" (or some other concept entirely) is more obvious, I'd be happy to see it used. From a couple of days of practice, I can say that --quit feels fine in a way that --reset didn't, but not much more. --reset is a cognate to "git reset", the command to make some combination of the HEAD, index, and worktree just so. In other contexts --- rebooting a machine, resetting an alarm clock --- to reset something also means to return it to a known state. By contrast, the "git cherry-pick --abandon" command is about leaving the state alone as much as possible while escaping from the context of a cherry-pick sequence. How does that do harm, though? My main fear is that people would not notice that --reset is the option they want to use and would opt to "rm -r .git/sequencer" instead, which is a kind of error-prone wizardry that should not be required. (I assume cherry-pick --reset was named by analogy with "git bisect reset", the command to abandon a bisection and return to the branch you were on before bisection, or a branch or commit named on the command line. Which is not analagous to cherry-pick --abandon at all. The command people often run, "git bisect reset HEAD", is a closer analog if you squint right.) -- 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