Be more aggressive about marking trees uninteresting
commit4311d328fee11fbd80862e3c5de06a26a0e80046
authorLinus Torvalds <torvalds@g5.osdl.org>
Sat, 23 Jul 2005 17:01:49 +0000 (23 10:01 -0700)
committerLinus Torvalds <torvalds@g5.osdl.org>
Sat, 23 Jul 2005 17:01:49 +0000 (23 10:01 -0700)
tree0c6727da4f1a0ab0d81beba8348235029da6601f
parenta692b9656a7975b933fde40cdd6319f9ca898a29
Be more aggressive about marking trees uninteresting

We'll mark all the trees at the edges (as deep as we had to go to
realize that we have all the commits needed) as uninteresting.
Otherwise we'll occasionally list a lot of objects that were actually
available at the edge in a commit that we just never ended up parsing
because we could determine early that we had all relevant commits.

NOTE! The object listing is still just a _heuristic_.  It's guaranteed
to list a superset of the actual new objects, but there might be the
occasional old object in the list, just because the commit that
referenced it was much further back in the history.

For example, let's say that a recent commit is a revert of part of the
tree to much older state: since we didn't walk _that_ far back in the
commit history tree to list the commits necessary, git-rev-tree will
never have marked the old objects uninteresting, and we'll end up
listing them as "new".

That's ok.
rev-list.c