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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 2, 2020, 19:52 UTC
Message-ID: <xmqqblioarcp.fsf@gitster.c.googlers.com>
In-Reply-To: <1006A7F3-8C48-46E3-8F7C-3F82181E3619@mit.edu>

Anish R Athalye <aathalye@mit.edu> writes:

Show 8 quoted lines

> 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.

Show 5 quoted lines

> 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.