Candidates for sequencer?

Candidates for sequencer?

[Ramkumar Ramachandra]

Hi,

I'd like to get more commands to call into sequencer.c, so that we can
(finally) implement a sensible `git continue` and `git abort`.
Currently, am and rebase come to mind, but they are shell scripts and
I don't see how we can make them call into sequencer.c.  Is there any
way to make sequencer.c more useful?  Should we implement a `git
continue` and `git reset` anyway, lifting code from 83c750ac to check
the tree state?

Ram

Re: Candidates for sequencer?

[Jeff King]

On Tue, Nov 13, 2012 at 03:16:51AM +0530, Ramkumar Ramachandra wrote:

> I'd like to get more commands to call into sequencer.c, so that we can
> (finally) implement a sensible `git continue` and `git abort`.
> Currently, am and rebase come to mind, but they are shell scripts and
> I don't see how we can make them call into sequencer.c.  Is there any
> way to make sequencer.c more useful?  Should we implement a `git
> continue` and `git reset` anyway, lifting code from 83c750ac to check
> the tree state?

I'd love it if ther was a mechanism for interruptible commands to notify
the rest of git that they are in progress. This would not only make
cross-language commands like "rebase" and "am" work easily, but it would
mean that we can automatically support third-party commands that we
don't even know about.

I am already doing something like this for some personal scripts which
do sequences of merges and rebases, and my "git continue" looks like:

  if test -f "$GIT_DIR/continue"; then
    eval "$(cat "$GIT_DIR/continue")"
  elif test -d "$GIT_DIR/rebase-merge"; then
    git rebase --continue
  elif test -d "$GIT_DIR/rebase-apply"; then
    if test -f "$GIT_DIR/rebase-apply/applying"; then
      git am --continue
    else
      git rebase --continue
    fi
  fi
  [... etc ...]

It works pretty well in practice, but I'd have a few suggestions on top:

  1. Even if "am" and "rebase" learn to use $GIT_DIR/continue, we should
     probably continue to support the fallback state-examination in case
     people use mixed versions of git. And clearly the code should be
     shared with what's in wt-status.c.

  2. The "continue" file should probably be called "in-progress", and
     should have more structured data, like the name of the operation.

  3. The list of operations in progress needs to be a stack. If I am
     rebasing and start a cherry pick, what would "git continue" do? It
     probably makes sense to continue the most recently started
     operation first.

  4. Rebase already detects an in-progress rebase. It should probably
     also detect an "am" or "cherry-pick" in progress. But it's not
     commutative; you should be able to start a "cherry-pick" in the
     middle of a "rebase". This is really independent of the storage
     format (we could do it right now if the state logic from wt-status
     is made available in a machine-readable format).

     We _might_ want to put information in the in-progress file that
     helps programs reach that decision. I'm not sure of a sane way of
     doing it, though. You could say "don't rebase while I'm in
     progress", but that depends on the writer knowing the universe of
     all programs that might be run. It might be possible to come up
     with some taxonomy of operations like "a history rewriting
     operation is in progress" which would cause other history rewriting
     operations to choose not to start. But coming up with the right set
     of attributes might be impossible.

-Peff