Re: git-rev-list: proper lazy reachability

Linus Torvalds wrote:

On Tue, 31 May 2005, Linus Torvalds wrote:

quoted

You should never see a parent before a child from git-rev-list.

Actually, I take that back.

...

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.

If this is an exception, and I it is, peraphs can be treated in a special way.

As example, when adding a new parent to the pending list of parents to be processed in time-based
ordering, should be easy to inc a counter if  the last one is always the same, e.g. there is the
same very old node around, and check closer to it if the counter reach some allowed maximum.

I know it's a hack, and is not a solution in the general case, but also the last century developer
clock is very rare, more, it is a warning for a bad commit. 

Do not wait for the end of the toposort its a very big advantage for, e.g. GUI git viewers
launched on big trees with long histories.

Marco Costalba




	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it