Re: rebase--interactive in C vs. sequencer
On Sat, 5 Apr 2008, Stephan Beyer wrote:
Show 9 quoted lines
> 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 commonFor 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 commitIIRC, 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*
Stephan Beyer