Hi again, Jonathan Nieder writes: > 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. Okay, although I'm not inclined to do this right away. >>> 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". *pants* That was quite a challenging rebase. I think I managed to get it right after several attempts -- we'll find out soon enough. -- Ram -- 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