On Sun, 12 Aug 2007, David Kastrup wrote:
quoted text
> >
> > 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).

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html