Re: [GSoC 2011] Git Sequencer

On Mon, 4 Apr 2011, Ramkumar Ramachandra wrote:

Here's how I'm thinking about a single step:

The non-conflict case is:

  $ git cherry-pick ...
  figure out what we're asked to do
  make the change to the working directory and index
  make the commit with info from the commit we're cherry-picking

The conflict case should be:

  $ git cherry-pick ...
  figure out what we're asked to do
  make the change to the working directory and index
  discover problem, set up for human assistance, tweak info to say that we 
    needed help
  $ fix stuff
  $ git continue
  check that everything is how it should be
  make the commit with info from the commit we're cherry-picking

That is, the code that cherry-picks one commit can quit in the middle and resume after the user finishes helping, and the main entry point to git can resume that operation.

So, my thought was that you'd have something like:

cherry_pick_conflict = { 
  "cherry-pick", APPLIES_TO_CURRENT_BRANCH | IN_MIDDLE_OF_COMMIT,
  cherry_pick_verify_resolution,
  cherry_pick_abort,
  cherry_pick_post_resolution
};

int cherry_pick(struct commit *item)
{
  save info on the commit, flags, etc needed to understand what we're doing

  try to apply diff...
  if (!rejected)
    return cherry_pick_post_resolution();
  try to use merge recursive...
  if (!conflict)
    return cherry_pick_post_resolution();
  return report_conflict(cherry_pick_conflict);
}

int cherry_pick_verify_resolution(void)
{
  if (still unmerged files) {
    describe work still needed
    return 1;
  }
  return 0;
}

int cherry_pick_abort(void)
{
  restore info on what we'd started and delete state

  clean up the working directory, index, etc

  return 0;
}

int cherry_pick_post_resolution(void)
{
  restore info on what we'd started and delete state

  make the commit

  return 0;
}

The important things are:

 - arbitrary code can determine that you're in the middle of resolving 
   some conflict, that the resolution of that conflict is about doing
   something to your current branch, and how to abort what you're doing,
   and how to finish it

 - the same code gets run after the conflict has been resolved that would 
   have been run immediately if the merge went smoothly

 - cherry-pick can save whatever it needs to in its state file; that's 
   its business, and the semantics here don't have to interact with other 
   commands, because report_conflict() has taken care of interaction with 
   other commands

The next step is to be able to have:

int sequencer()
{
  save the list of steps, with no in-progress step
  return sequencer_post_resolution();
}

int sequencer_post_resolution()
{
  finish any in-progress step
  get the next step
  if (no steps left)
    return 0;
  attempt step
  if (!got_conflict)
    return sequencer_post_resolution();
  return report_conflict(sequencer_conflict);
}

Where the sequencer-level conflict nests around the cherry-pick-level conflict, and the generic "continue" completes things from the inside out.

I think, ultimately, that with this code structure in place, the am/rebase/rebase--interactive/sequencer details of how the multi-step process is recorded becomes less important. That way, your project can be successful even if you can't find a syntax for the sequencer file that meets the needs of all of these use cases. (Which is where I suspect you'll get bogged down.) If you can get all of the cases where git exits in order to get human intervention to share "everything that matters" and the core to "know what's in progress as far as anything else cares", I think that would be success, even if the various multi-step programs continue using their own state files.

	-Daniel
*This .sig left intentionally blank*