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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Sat, 24 Jan 2009, Thomas Rast wrote:

> Johannes Schindelin wrote:
> > Worse, the whole concept of "pick <merge-sha1>" just does not fly well.
> [...]
> > - merge $sha1 [$sha1...] was $sha1 "Merge ..."
> > 
> > 	will merge the given list of commits into the current HEAD, for 
> > 	the user's reference and to keep up-to-date what was rewritten, the 
> > 	original merge is shown after the keyword "was" (which is not a valid 
> > 	SHA-1, luckily)
> 
> I really like the underlying idea.  I'm not even sure if the current 
> semantics are well-defined in all cases; an explicit merge command at 
> least makes it very clear what is going on.
> 
> However, I think the syntax as proposed above is a bit confusing in the 
> usual two-parent merge.  I couldn't tell whether
> 
>   merge A was B
> 
> was intended to be read as "the merge of A into the current branch" or 
> "the merge with sha1 A" right away, and I doubt I'll be able to tell 
> without looking in the (rare) cases I have to invoke rebase -i -p.
> 
> I can't really come up with a better replacement for 'was', so how about
> 
>   merge A  # was B "Merge..."
> 
> which would make it more clear that the "was B..." has no effect 
> whatsoever on the merge's semantics.

Hmm.  You're right, that is not really intuitive.  How about

	merge (B) A # Merge...

instead?

> > A - B - - - E 
> >   \       /
> >     C - D
> > 
> > could yield this TODO script:
> > 
> > 	pick A
> > 	pick C
> > 	pick D
> > 	goto A'
> > 	pick B
> > 	merge D' was E
> 
> I kind of wonder if it would be possible to decorate the TODO with
> 'git log --graph' output, to make it easier to follow the history as
> it is built.

I wondered about that, too, and abandoned it as my common operation is cut 
& past lines around.  The result would look _utterly_ confusing.

Maybe I should have mentioned that to spare you the brain cycles thinking 
about --graph...

Ciao,
Dscho