From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sun, 14 Aug 2011 16:48:19 GMT
Subject: Re: [PATCH 7/7] sequencer: Remove sequencer state after final commit
Message-ID: <20110814164819.GA12747@elie.gateway.2wire.net>
In-Reply-To: <CALkWK0m0KyZkOqVWJET=_Xy5GxwVfpPkB0OO1b2hJ8aN_x7hGA@mail.gmail.com>

Ramkumar Ramachandra wrote:

> Putting an "int aggressive = 1" and passing the variable instead of
> the literal is a little inelegant.

What about a flag word, like for example read_sha1_file_extended()
takes?

[...]
>> Do you think there might
>> be scripts out there relying on being able to use "git read-tree
>> --reset -u HEAD" to clear away a failed cherry-pick before trying
>> again, and if so, can we do something about it?
>
> I'm not sure we can do anything about it -- we should probably put
> some kind of warning in the commit message?

That's necessary at a minimum.

I actually _don't_ think there might be many scripts relying on "git
read-tree --reset -u HEAD" to clear away a failed cherry-pick, simply
because very few people seem to use plumbing these days :) and those
who do might be of a mindset to use "git apply" instead of
cherry-pick.  But it would be prudent to run a code search to check
and to think carefully about the effect on people who did use the
"read-tree --reset && cherry-pick again" idiom.

Hope that helps.
Jonathan