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