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

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