From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Wed, 06 Jul 2011 10:55:02 GMT
Subject: Re: [PATCH 12/14] revert: Introduce --reset to cleanup sequencer data
Message-ID: <CALkWK0mLaCy3LePYYEpby-sd9Z2a=DWq4uWvFiadin7sa_h2+w@mail.gmail.com>
In-Reply-To: <20110706101423.GI15682@elie>

Hi,

Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>>  This is perfect but for the fact that 'git reset --hard' doesn't blow
>>  away the sequencer state.  Why I haven't implemented that yet: should
>>  ONLY a hard reset blow away the state?
>
> I don't know.  What do you think?

I personally don't think any other kind of reset would warrant blowing
away the sequencer state.

> The constraints I see are:
>
>  1. outside scripts that use "git cherry-pick" should continue to work
>
>  2. as a small indication that that's vaguely possible, unrelated parts
>    of the test suite should not need to be patched

I don't see how this is possible.  I'm tempted to say that we should
call this new cherry-picking mechanism with the sequencing
functionality something else like "git sequencer"; then it's possible
to avoid breaking existing scripts.

>  3. when a person uses commands like "git reset --hard" without
>   _intending_ to blow away the sequencer state, it should be possible
>   to get the sequencer state back.

I like your suggestion here -- simply move .git/sequencer to
.git/sequencer-old or similar :)

> For dealing with "git rebase --interactive" and similar porcelain-ish
> scripts, the CHERRY_PICK_HEAD code-path has its own trick of falling
> back to traditional behavior when the GIT_CHERRY_PICK_HELP environment
> variable is set (see v1.5.4-rc0~106^2~1, revert/cherry-pick: Allow
> overriding the help text by the calling Porcelain, 2007-11-28).

Ah, I see.

-- Ram