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 [off-list ref], PGP 0x6EDDD207FCC5040F
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*