Re: Heads up: major rebase -i -p rework coming up

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 24, 2009, 21:04 UTC
Message-ID: <alpine.DEB.1.00.0901242156320.14855@racer>
In-Reply-To: <7vpricmoda.fsf@gitster.siamese.dyndns.org>

Hi,

On Sat, 24 Jan 2009, Junio C Hamano wrote:

Show 19 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > 	pick A
> > 	pick C
> > 	pick D
> > 	goto A'
> > 	pick B
> > 	merge D' was E
> >
> > This should lead to a much more intuitive user experience.
> >
> > I am very sorry if somebody actually scripted rebase -i -p (by setting 
> > GIT_EDITOR with a script), but I am very certain that this cleanup is 
> > absolutely necessary to make rebase -i -p useful.
> 
> Three questions.
> 
> - An obvious one first.  How does this relate to the sequencer project 
>   (that seems to have gone somewhat dark?)

As far as I can see, Stephan can keep the "mark" command he cherishes so much, and we can still use thise syntax for rebase -i -p.

Show 9 quoted lines

> - What's with the apostrophe?  I seem to remember that you argued it 
>   would be enough to make "A" stand for the original when it is used for 
>   the first time and the second and later use can stand for the result 
>   of the last use (e.g. the "goto A'" above can be simply spelled as 
>   "goto A"), when I suggested to use "mark" in a way similar to how 
>   fast-import language uses it during the sequencer discussion?
> 
>   I am not complaining; I am just being curious why the sudden change of 
>   heart.

Very easy explanation. I got convinced by your arguments. Even if I could imagine that I never use the thing without apostrophe, it is good to have an obvious indicator that this is not necessarily the original commit.

Show 7 quoted lines

> - Why do you need "merge D' was E"?  Shouldn't "pick E" be able to 
>   notice that E is a merge and decompose it into "merge D' was E" 
>   internally?
> 
>   This one I am somewhat complaining, unless your answer is "because 
>   this way the user could drop some parents from the merge in the 
>   editor".

Not only that; the user could use this to fix mismerges, i.e. by replacing a SHA-1 with the SHA-1 (or indeed, a short name, unless it is "was") of the branch that she _actually_ wanted to merge with.

>   And if your answer is that, then my next question will be "if that is 
>   the case, can the user be expected to easily find out which commit 
>   each parent SHA-1 refers to, without having more hint on the 'merge' 
>   insn line?"

Nope.

In most cases, however, that should be plenty enough:

	merge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next

The user does not have to guess much what 9383af1 might refer to.

In case of octopodes, or when the commit message was changed, the user has to open another command line and look for herself, though.

Ciao, Dscho