Re: git-rev-list: proper lazy reachability

On Tue, 31 May 2005, Linus Torvalds wrote:

Actually, I take that back.

A commit that has several children will see _a_ child before the parent is shown, but while the time-based ordering means that it _likely_ will order all children before the parent, now that I think about it, that's not guaranteed to be true. You could have

	      A
	     / \
	    B   |
	     \ /
	      C
	      |
	      D

and if C has a date that is before B, then git-rev-list would traverse the tree (and show it) in the order A C B.

In fact, even D might be listed before B is (eg, the person who committed B had a clock that was set to the last century, and so the date on that was wrong).

The thing is, since B has such an "old" date, the traversal assumes that it is old and very low down in the tree, and that it's better off parsing other commits first, so it will never look more closely at B and notice that it has a parent that has already been parsed.

So I guess you'll have to wait for the end and do the toposort after all. Sorry about the confusion on my part.

		Linus