False alarms from git-fsck(1) about missing commits/trees pushed after the run started

Ævar Arnfjörð Bjarmason· Feb 28, 2011, 12:38 UTC · lore

I ran `git-fsck --full --verbose` on a bare Git repository which users push to (over ssh).

It reports things like this:

    missing commit c7836745b13ce838439b3705d3c5c93bc0add6a6
    missing tree ef59d2bee486b6af5ae36eb9ff2e9de0d52f37ab
    missing commit 786315c755ac91d3a1ffc3d92679dda961035617

But actually these things aren't missing. They were just pushed to the repo after the fsck run started.

Is this a known limitation of git-fsck, is it documented anywhere? If it's not supposed to do this maybe there's a race condition somewhere in it.

Junio C Hamano· Feb 28, 2011, 16:23 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: False alarms from git-fsck(1) about missing commits/trees pushed after the run started

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> But actually these things aren't missing. They were just pushed to the
> repo after the fsck run started.
>
> Is this a known limitation of git-fsck,...

Yes.

We validate the contents of the objects we find in the repository (we do this by directly visiting .git/objects/??/ and .git/objects/packs/ directories and validate the contents of even unreachable objects), mark their existence while doing so, and then traverse the reachability DAG from refs to find dangling & missing.

It always is possible to have objects we mark as reachable in the second phase that are not marked as existing in the first phase if you are actively adding objects to the repository (e.g. by pushing into it, by fetching into it, or by running "git add") while running fsck, as these new objects may not exist during the first phase but then later can become reachable by ref updates.

> ..., is it documented anywhere?

I don't know for sure but I doubt it; please make it so.