* Bug report: git cat-file -e / rev-list disagree with git fsck on empty tree
@ 2020-09-02 0:27 Anish R Athalye
2020-09-02 19:52 ` Junio C Hamano
0 siblings, 1 reply; 2+ messages in thread
From: Anish R Athalye @ 2020-09-02 0:27 UTC (permalink / raw)
To: git@vger.kernel.org
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.
However, in the same situation:
$ git fsck
[...]
missing tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Bug report: git cat-file -e / rev-list disagree with git fsck on empty tree
2020-09-02 0:27 Bug report: git cat-file -e / rev-list disagree with git fsck on empty tree Anish R Athalye
@ 2020-09-02 19:52 ` Junio C Hamano
0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2020-09-02 19:52 UTC (permalink / raw)
To: Anish R Athalye; +Cc: git@vger.kernel.org
Anish R Athalye <aathalye@mit.edu> 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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-09-02 19:52 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-02 0:27 Bug report: git cat-file -e / rev-list disagree with git fsck on empty tree Anish R Athalye
2020-09-02 19:52 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).