Re: [PATCH 10/17] sequencer: Announce sequencer state location
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Jul 17, 2011, 19:19 UTC
- Message-ID
- <20110717191931.GH27787@elie>
- In-Reply-To
- <CALkWK0k1pX6rjGh8U6ZdDFk3qFcbj-UjU-Q-Z76hn6HV46pncg@mail.gmail.com>
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.
Show 9 quoted lines
>> 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