[RFC] Issues around C rebase--interactive

[RFC] Issues around C rebase--interactive

[Daniel Barkalow]

I'm working on porting rebase--interactive to C. This has a number of 
interesting issues:

This will be the first C command which stops in the middle and then gets 
resumed. I've been thinking it would be nice if all of the commands like 
that shared handling of the process in some way. I think it would be good 
to have a "git abort" that would reset a conflicted merge, abort a rebase, 
etc., and probably "git checkout" should either require that there's 
nothing in progress or should abort anything that is in progress. (You can 
presently get lots of fun confusion by starting a rebase, checking out a 
different branch, deleting the branch that you were rebasing, attempting 
another rebase and trying to clean up.)

It would also be nice to have a "git resume" that would continue whatever 
needed user attention after you've done it. (But you'd still need "git 
rebase skip" to do that command-specific first step before resuming.)

There's a lot of stuff stored presently in ways that are convenient for 
shell scripts and inconvenient for C. Is anything else depending on the 
contents or location of ".git/.dotest-merge"?

	-Daniel
*This .sig left intentionally blank*

Re: [RFC] Issues around C rebase--interactive

[Johannes Schindelin]

Hi,

On Sun, 17 Feb 2008, Daniel Barkalow wrote:

> There's a lot of stuff stored presently in ways that are convenient for 
> shell scripts and inconvenient for C.

We could have both, actually.  There could be a ".git/state" to tell git 
abort/resume what the current actions are, and in addition the files that 
used to be there, too.

> Is anything else depending on the contents or location of 
> ".git/.dotest-merge"?

This has been discussed recently.  I offered the opinion that some 
people's scripts might rely on the location, but was all but shot down.  I 
guess we'll have to change it to find out.

Ciao,
Dscho

Re: [RFC] Issues around C rebase--interactive

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> ... I think it would be good 
> to have a "git abort" that would reset a conflicted merge, abort a rebase, 

Yes, we would want a consolidated "git sequencer" that can be
reused by "am" and "rebase".  The command set to the sequencer
would be a slight superset to what rebase--interactive uses in
its todo file, I would imagine.  To support "am" (and non-merge
version of "rebase") it would add "apply <filename>" command.