On Sun, 12 Aug 2007, David Kastrup wrote: > > > > rev-list doesn't try to draw a line from each commit to its parents. > > Well, that's what --topo-order is somewhat about, but it might > actually not do much together with --all. No, --topo-order works with --all too. In fact, to some degree, it's *especially* useful with --all, since having multiple tips makes the whole topological sort all the more interesting, and also usually makes the end result more interesting (ie it's often much more interestign to visualize two or more branches together, just to see the *relationships* between the branches, and see what is shared. And yes, it keeps track of every single commit, and computes the relationships between them. So it does indeed "draw the line", except it can do so in a rather dense and optimized set of data structures. (That's one reason I love coding in C: it may be more effort, but you can tune your data structures in ways you seldom can in higher-level languages, and git-rev-list and the object representation is some of the most tuned code in git). > 20 bytes of payload for a commit number. Make a usable hashing data > structure for it, adds perhaps another 20 bytes. Links to all parents > are 4 bytes each. All in all, we won't need more than 64 bytes per > commit. Yeah, that's the rough ballpark (except for 64-bit architectures, the links are all 8 bytes, but we're pretty careful). See "object.h" for most of the details. Linus - 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
