Re: [GSoC 2011] Git Sequencer

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 5, 2011, 17:50 UTC
Message-ID: <20110405175003.GA12159@kytes>
In-Reply-To: <alpine.LNX.2.00.1104041319570.14365@iabervon.org>

Hi Daniel,

Daniel Barkalow writes:

Show 16 quoted lines

> On Mon, 4 Apr 2011, Ramkumar Ramachandra wrote:
> > Ramkumar Ramachandra writes:
> > > Daniel Barkalow writes:
> > > > I actually think that it would be a worthwhile feature for git's library 
> > > > code to have a uniform mechanism for communicating that it is requesting 
> > > > human intervention in the middle of a particular operation, where library 
> > > > operations which conflict with being able to continue this operation are 
> > > > either blocked or abort the operation, and the library is able to be told 
> > > > in general that the human intervention is done and the library operation 
> > > > should be finished now (or produce complaints about the user's work). That 
> > > > is, a library-level, single-interrupted-step "sequencer". For that matter, 
> > > > it should also apply to the common '"git merge" gets a conflict' case, and 
> > > > it would be useful to get some representational uniformity between that 
> > > > and cherry-pick getting a conflict.
> > 
> > [...]

Thanks for the detailed response- I've rearragned your response and added some comments. I initially wanted to design it so that all state is persisted by the sequencer, but I can clearly see what's wrong with that approach now.

Show 10 quoted lines

> 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.

Excellent. The crux of the idea: The sequencer should serve as the entry/ exit point for Git when any operation requires user intervention to proceed. For this, it should have information about how we got to this point, and how to proceed after the user intervention is complete; this information is contained in:

Show 6 quoted lines

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

Wait -- isn't it missing a skip callback?

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

This information is passed to report_conflict(), which takes care of user intervention. The user can do whatever she wants and then ask the sequencer to "continue", "skip" or "abort":

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

Right. And then the sequencer fires the appropriate callback and returns control to the parent command. More notes:

>  - 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

At the end of a merge for example, the MERGE_MSG needs to be retrieved to create a new merge commit. The sequencer des not need to know anything about this, since this is specific to 'merge'.

>  - 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

Any arbitrary code simply has to ask the sequencer about the state of the intermediate files that report_conflict() uses. They don't have to worry about command-specific intermediate files.

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

Using these callbacks, there is no need for if-else ugliness inside the specific command to decide what to do next.

I suppose we can call this idea a "generic conflict handler". I like it very much, and I'll definitely include this as part of my GSoC work. Thanks for taking the time to explain it in such detail :)

-- Ram