On Thu, Jan 18, 2024 at 12:15:08PM +0100, Patrick Steinhardt wrote:

quoted

I am guessing that "git fsck" does not check file packed-refs at all.
I mean, it does not even attempt to parse it, in order to check
whether at least the format makes any sense. Only "git push" does it.

Indeed it doesn't. While the issue is comparatively easy to spot by
manually inspecting the `packed-refs` file, I agree that it would be
great if git-fsck(1) knew how to check the refdb for consistency. This
problem is only going to get worse once the upcoming reftable backend
lands -- it is a binary format, and just opening it with a text editor
to check whether it looks sane-ish stops being a viable option here.

We don't check the packed-refs file explicitly, but we do open and parse
it to iterate over the refs it contains. E.g.:

  $ git init
  $ echo foo >.git/packed-refs
  $ git fsck
  Checking object directories: 100% (256/256), done.
  fatal: unexpected line in .git/packed-refs: foo

It's quite possible that the reading code could be more careful. I'd
have to see the exact corruption that "git fsck" didn't complain about
to say more.  If there's a page full of NUL bytes at the end of the
file, I wouldn't be surprised if the reading code gently ignores that,
which obviously is not ideal.

Fundamentally we cannot catch all cases here; a simple truncation, for
example, might yield a valid file that is simply missing some entries.
Unlike objects (which make promises about reachability and so on), there
is no real "consistency" for the state of the refs. But probably warning
if saw a bunch of garbage in the file is a good thing.

I also agree that a specific refdb consistency check would be valuable.
There are some things that the regular reading code will not check, but
which an fsck should (e.g., if the packed-refs file claims to have the
"sorted" trait, we should confirm that).

-Peff