Jeff King [off-list ref] writes:
quoted
This code comes originally form 454fbbcde3 (git-rev-list: allow missing
objects when the parent is marked UNINTERESTING, 2005-07-10). But later,
in aeeae1b771 (revision traversal: allow UNINTERESTING objects to be
missing, 2009-01-27), we marked dealt with calling parse_object() on the
parents more directly.
So what I wonder is whether this code is simply redundant and can go
away entirely. That would save the has_object_file() call in all cases.
Hmm, interesting. I forgot all what I did around this area, but you
are right.
There's a similar case for trees. ...
though technically the existing code allows _missing_ trees, but
not on corrupt ones.
True, but the intention of these "do not care too much about missing
stuff while marking uninteresting" effort is aligned better with
ignoring corrupt ones, too, I would think, as "missing" in that
sentence is in fact about "not availble", and stuff that exists in
corrupt form is still not available anyway. So I do not think it
makes a bad change to start allowing corrupt ones.
I guess this is perhaps less interesting, because we only mark trees
directly fed from the pending array, not every tree of commits that we
traverse. Though if you had a really gigantic tree, it might be
measurable.
I tend to agree that this is less interesting case than commits.
A huge tree with millions of entries in a single level would spend
quite a lot of cycle in slurping the tree data to in-core buffer,
but we do not actually parse these million entries upon opening the
tree, so it may not be too bad.