Git development
 help / color / mirror / Atom feed
From: Daniel Barkalow <barkalow@iabervon.org>
To: Stephan Beyer <s-beyer@gmx.net>
Cc: git@vger.kernel.org
Subject: Re: rebase--interactive in C vs. sequencer
Date: Sun, 6 Apr 2008 17:44:54 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LNX.1.00.0804061724210.19665@iabervon.org> (raw)
In-Reply-To: <20080405122230.GC14565@leksak.fem-net>

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*

      reply	other threads:[~2008-04-06 21:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-05 12:22 rebase--interactive in C vs. sequencer Stephan Beyer
2008-04-06 21:44 ` Daniel Barkalow [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.1.00.0804061724210.19665@iabervon.org \
    --to=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=s-beyer@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox