Re: [GSoC 2011] Git Sequencer

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 4, 2011, 04:06 UTC
Message-ID: <20110404040610.GA30737@kytes>
In-Reply-To: <alpine.LNX.2.00.1104031407480.14365@iabervon.org>

Hi Daniel,

Daniel Barkalow writes:

Show 17 quoted lines

> On Sun, 3 Apr 2011, Ramkumar Ramachandra wrote:
> > To write git-sequencer, a new builtin command, and implement existing
> > commands on top of that.  This should give the commands more
> > functionality, improve their error handling, and make them faster.
> > The project can only be considered successful if all (or most) of the
> > code written gets merged into upstream.
> > 
> > The Git Sequencer was a 2008 GSoC project as well; unfortunately most
> > of the code did not get merged into git.git.  The learning from all
> > that work should serve as a huge headstart this year.
> 
> One of the things that is hard about sequencer is that it is ultimately a 
> complete replacement for several differently-implemented programs in 
> different languages, with different temporary file formats and differrent 
> supported operations. As such, you could probably spend an entire summer 
> just getting it reviewed, revised, and accepted, starting with a working 
> implementation.

Agreed. I've chosen to use the same commands and temporary files as 'git-rebase--interactive.sh', because I think those commands are sufficient to implement everything else.

Show 6 quoted lines

> So I think your proposal is good in how [1/5] includes getting something 
> useful merged. My suspicion is that the outcome will be something like 
> that you implemented all 7 tasks and got 4 of them merged, assuming that 
> you really push getting things merged as soon as they're ready, without 
> spending too much time porting other things to use the core and getting 
> the ports reviewed before the core is accepted.

Hm. In that case, we'll just have a sequencer that can cherry-pick -- I personally wouldn't be too happy with this outcome either.

Show 11 quoted lines

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

Until 4/7, I'd only planned to make the 'git-sequencer' binary like the 'git-rebase--interactive.sh' script, except that it would accept a TODO file on stdin, instead of interactively opening up an editor.

Your idea is a slightly more ambitious version of what I'd planned for 6/7, especially since 'merge' contains a lot of cruft like MERGE_HEAD and CHERRY_PICK_HEAD. I can shift my focus after 4/7 though -- here's what I have in mind. Do you have something similar in mind?

enum commit_todo_action {
     ACTION_PICK;
     ACTION_REWORD;
     ACTION_EDIT;
     ACTION_SQUASH;
     ACTION_FIXUP;
     ACTION_EXEC;
};

struct commit_todo_list {
       struct commit *item;
       enum commit_todo_action action;
       struct commit_todo_list *next;
};

int sequencer_cherry_pick(struct commit *base, struct commit_list *list); int sequncer_rebase(struct commit *base, struct commit_todo_list *list); int sequencer_handle_conflict(); /* Returns ABORT (1) or RESOLVED (0) */

/**
 * The sequencer_handle_conflict function essentially starts with a
 * working tree with unmerged files and results in either a working
 * tree without unmerged files (in which case it returns 0), or simply
 * returns 1.  Advantage: Consistency. Each individual script will not
 * have to maintain its own temporary files.
 */

Show 6 quoted lines

> I think replacing existing multi-step processes is going to be a lot more 
> contentious and involve user-visible changes which involve matters of 
> taste and such. But I think you can make a valuable contribution in how a 
> single current step is handled before getting tangled in that, and be much 
> more likely to get a useful outcome than if you try to tackle the whole 
> problem.

Okay. I'll replace 5/7 - 7/7 in my proposal with an alternative as soon as I sketch out the details more clearly.

Thanks for your suggestions!

-- Ram