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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Aug 18, 2011, 20:06 UTC
Message-ID: <CALkWK0nV35gNFM2NW-FrwBLnvFzmWDdARZk0Xy6LT8c2UE0fAw@mail.gmail.com>
In-Reply-To: <CALkWK0=jRAq6s1zQ5gwB4feBgC1eo=VYLWx8bsjs+exqmz0f1A@mail.gmail.com>

HI again,

Ramkumar Ramachandra writes:

Show 5 quoted lines

> One final resort: Move some code back into cherry-pick, and call into
> a later-function in the sequencer only if it's a many-commit
> operation.  The new commands can enjoy the comfort of calling into an
> earlier-function in the sequencer that'll do all the revision walk
> setup and call the later-function.  I think this is reasonable.

Er, no. This would be amazingly ugly too: we'd need two versions of everything like '--continue'. And look at this glaring inconsistency:

  git cherry-pick foo..bar
  ..conflict..
  git sequencer --abort
  $? = 0

But:

  git cherry-pick foo
  ..conflict..
  git sequencer --abort
  error: No sequencer operation in progress.

In a nutshell, the problem we're facing: We persist part of the continuation data outside the sequencer's knowledge, and part of it inside. For backward compatibility, we can't move the former part into the sequencer.

-- Ram