On Thu, 1 Jun 2006, Junio C Hamano wrote: > > You're much better off using "gitk --all" if you want to see the result, > > the "show-branch" this is really broken. It is using the old algorithm > > that we used to use for "git-rev-tree", and got rid of about a year ago > > there in favour of git-rev-list ;) > > Are you sure about it? My recollection is it uses the > merge-base logic, naturally enhanced for multiple heads. Well, it's all the same algorithm, where just the bit usage differs. git-rev-tree is slightly closer, if only because the original git-merge-base only did two heads, if I recall correctly (while git-rev-tree did 16 - the ability of git-show-branch to do 29 came from just using all the free bits rather than the high bits like rev-tree did) > And enhancing it to support more than one int wide bitmap should > not be too difficult, although looking at the output would be > very taxing for human eye, so I do not know if it is worth it. Yeah, I don't think there is any reason to really support it. If you have more than a few heads, you really do need the graphical version to see what is going on, and git-show-branch doesn't buy you anything. 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