rebase--interactive in C vs. sequencer

rebase--interactive in C vs. sequencer

[Stephan Beyer]

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

Hi Daniel,

in [1] you have told that you are working on porting rebase--interactive
to the C programming language.  In reply, Junio pointed out that a
consolidated "git sequencer" is desired.

The sequencer became a project idea for Google Summer of Code and I am
currently applying for that project.  But I had your mail in mind and 
do not want that any work of yours is thrown away. ;-)
So... what is the current state?
Are you still working on it?
Is there a code stub or even more code which could be used for the
sequencer task?

Regards,
 Stephan

References:
 1. http://marc.info/?l=git&m=120327576215702

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: rebase--interactive in C vs. sequencer

[Daniel Barkalow]

On Sat, 5 Apr 2008, Stephan Beyer wrote:

> Hi Daniel,
> 
> in [1] you have told that you are working on porting rebase--interactive
> to the C programming language.  In reply, Junio pointed out that a
> consolidated "git sequencer" is desired.
> 
> The sequencer became a project idea for Google Summer of Code and I am
> currently applying for that project.  But I had your mail in mind and 
> do not want that any work of yours is thrown away. ;-)

It's at git://iabervon.org/~barkalow/git/ builtin-rebase-int

> So... what is the current state?

I was mainly working from rebase--interactive, and a lot of what I have is 
the code for the particular steps that uses.

> Are you still working on it?

Not at the moment. I've been busy with a new job recently, and my git work 
has mainly been on builtin-clone.

> Is there a code stub or even more code which could be used for the
> sequencer task?

I haven't actually looked at it recently, so I don't entirely remember how 
far I got. I think my most recent code is based around the idea of having 
a sequence file and a file of saved options, but it's just kind of a 
sketch and most of the stuff isn't actually implemented. IIRC, the last 
thing I ran into was trying to decide where to leave the line for the step 
in progress. I think I'd settled on a set of operations that a step should 
define:

 a) try doing the step, which either works and you go to (c), or it 
    requires user assistance and you exit now and later start at (b)
 b) apply the stuff the user did to help
 c) finish up anything common

For example, merging would be:

 a) try an automatic merge; if it works, succeed, otherwise, write out 
    conflict files and exit
 b) check that the index is merged
 c) make a merge commit

IIRC, for some operations (b) was more interesting, because the case that 
didn't have user assistence generates the final state differently and 
there's less in (c).

	-Daniel
*This .sig left intentionally blank*