From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Sun, 12 Jun 2011 12:09:05 GMT
Subject: Re: [RFC PATCH v2] revert: Implement --abort processing
Message-ID: <BANLkTi=T0wCg1bKzmtQEQ-J-5ogqRZaqRg@mail.gmail.com>
In-Reply-To: <20110611112213.GA25268@elie>

Hi Jonathan,

Jonathan Nieder writes:
> The documentation could say:
>
>        To wipe out everything and get back to where you started, use:
>
>                git reset --hard PRE_CHERRY_PICK_HEAD

My notion of --abort has changed: I simply want to remove the state
files for the cherry-pick so that the user can execute more
cherry-pick/ revert commands.  I didn't think a soft reset would be
intrusive.  Hm, you're suggesting using a ref -- I was wondering what
to do with CHERY_PICK_HEAD.  I'm not entirely convinced, but I'll wait
for the others to comment and think about this for some time.

> What if instead of --abort something else were simpler to think about?
> As a random example, I can imagine a "git sequencer --edit" command
> that would present the sequence in an editor and let me revise the
> plan --- would that do the trick?
>
>        1
>        2
>        3
>        4
>        * YOU ARE HERE
>        5
>        6
>        7
>        8
>
>  - Remove lines 5-8: removes sequencer state, leaves HEAD as is
>  - Remove everything: rewinds to abort sequence
>  - Add a line 2.5 between 2 and 3: rewind to 2, cherry-pick 2.5,
>   continue.

Interesting perspective.  I essentially have to keep two TODO files
and run a diff until I find the first different line.  Then, I have to
reset to that SHA-1 and replay the rest of the user-edited TODO.  Can
be complicated to get right, but it seems like quite an elegant
interactive solution.  It takes care of all three: --abort and --skip.
 We'd still need a --continue to non-interactively continue after a
conflict resolution though, no?

> Which is to say: if you have a story about what --abort will be used
> for, the life of others evaluating the thing becomes better and the
> upsides and downsides can be seen in perspective.  A story like "am
> and rebase have --abort, so cherry-pick should have one, too" is
> harder to think about.

I agree.  There's little point in being stuck with historical
conventions -- we should try something new and see how it works out :)

Thanks.

-- Ram