On Thu, 2 Mar 2006, Junio C Hamano wrote: > > And you had lt/rev-list branch first listed in FETCH_HEAD. In > this particular example, lt/rev-list has only 3 commits on top > of common things, but if your max were 3 instead of 10, the > first round would actually show the tip 3 without showing any > common stuff, and then the next round to show fk/blame branch > would show only the remaining two, without ever showing the > common stuff, even though it _could_ say the latest of the > common stuff. Yes. I considered it briefly, and it's fixable, but to fix it you'd have to actualyl walk the parent list yourself, rather than letting get_revision do it all for you. And what my simple thing shows isn't really technically "wrong", since it has shown that there are commits missing from the output with the "..." The question is just whether shared commits should be "balanced out", or shown as part of the first branch that merged them. I chose the latter, because it's not only simple, it's unambiguous (any balancing algorithm will depend on some random heuristic or other, and on how many commits are shown. > > - the old one did some formatting of the branch message that I don't > > follow because I'm not a perl user. The new one just takes the > > explanatory message for the branch merging as-is. > > FETCH_HEAD has explanatory message in more or less "canonical" > form. It has noise word "branch", and the current repository is > typically " of .". Yeah, I actually looked at a few examples, so I knew what it was basically trying to do, and then I ignored it as not interesting to the exercise, which was to abuse the new revision listing library in interesting ways by calling it multiple times. Linus - : 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