From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Mon, 04 Apr 2011 04:54:41 GMT
Subject: Re: [GSoC 2011] Git Sequencer
Message-ID: <20110404045437.GA2208@kytes>
In-Reply-To: <20110404040610.GA30737@kytes>

Hi Daniel,

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.

[...]

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

Uh, no.  I wrote this part in too quickly.  Clearly needs more
thought.

-- Ram