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.
> 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
Attachment:
signature.asc
Description: This is a digitally signed message part.
