Ramkumar Ramachandra wrote: > I don't think we should advertise it on stdout or stderr. I think of > a safeguard that only very few people will use. Ofcourse, documenting > it somewhere like Documentation/technical will make sense once we have > something usable. Yuck. Documentation/technical is for API, protocol, and design documentation. One should not need to read Documentation/technical in order to be able to use git! If the worry is that such a hint would be too noisy, it can be protected by a configuration variable using the usual advice mechanism. >> If I were doing it, I'd squash this with the patch that introduces >> "git cherry-pick --quit", to give an example of how the new function is >> meant to be used (and tests!). > > I would have done that too, except that the "reset: Make hard reset > remove the sequencer state" patch depends on this. So, I don't think > it's fair to squash it into either patch. > I can definitely write a better commit message though (wait for the > next iteration to see it). Would it be possible to introduce "cherry-pick --quit" here, and make the later patch only do one thing, namely adding the check to prevent a cherry-pick in the middle of a pending cherry-pick? In other words, I don't understand why the "reset --hard" workaround would need to come before "cherry-pick --quit". Thanks for explaining. Jonathan -- 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