Re: Bug report: git cat-file -e / rev-list disagree with git fsck on empty tree

Anish R Athalye [off-list ref] writes:

This is related to the change made in f06ab027efd2 (rev-list: allow cached
objects in existence check).

That patch seemed designed to allow the workflow where the empty tree is
missing from the object store, so
`git cat-file -e 4b825dc642cb6eb9a060e54bf8d69288fbee4904` and
`git rev-list --objects 4b825dc642cb6eb9a060e54bf8d69288fbee4904`
both return success even when the object is not physically present.

That sounds buggy.  I know git knows about both empty tree and empty
blob, but replacing the empty tree object name with the empty blob
object name in the above in a freshly-created empty repository gives
me errors from both of them, which is what I'd expect.

However, in the same situation:

    $ git fsck
    [...]
    missing tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904

... and if some other tree references to the empty tree (which is
unusual---I do not think we record such a tree, but some third-party
tools might), it is understandable fsck would complain.

I'm not sure if this is the intended behavior (the tree is indeed missing, so
in some sense, this is reasonable). But it seems somewhat confusing that it
disagrees with the interrogation commands.