Re: [PATCH 7/7] sequencer: Remove sequencer state after final commit

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Aug 14, 2011, 16:48 UTC
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?

[...]

Show 7 quoted lines

>> 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