From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Mon, 18 Jul 2011 19:44:31 GMT
Subject: Re: [PATCH 10/17] sequencer: Announce sequencer state location
Message-ID: <CALkWK0n4yXJ8HvCzcXMUda6oUyC2M32n25Sn5oKPzw0Huqvo8g@mail.gmail.com>
In-Reply-To: <20110717191931.GH27787@elie>

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