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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

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

> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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.

> - 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.

> - 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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux