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

From: Thomas Rast <trast@student.ethz.ch>
Date: Jan 24, 2009, 22:47 UTC
Message-ID: <200901242347.23187.trast@student.ethz.ch>
In-Reply-To: <alpine.DEB.1.00.0901242056070.14855@racer>

Johannes Schindelin wrote:

> Worse, the whole concept of "pick <merge-sha1>" just does not fly well.

[...]

Show 6 quoted lines

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

Show 12 quoted lines

> 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. Perhaps something like

  *   pick A
  |\
  * | pick B
      goto A'
  | * pick C
  | * pick D
  |/
      goto B'
  *   merge D'  # was E

Well, maybe it's not such a good idea after all.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch