Re: Unexpected cat-file --batch-check output

From: Bryan Turner <bturner@atlassian.com>
Date: Oct 26, 2021, 23:58 UTC
Message-ID: <CAGyf7-Gaphb9q=4cyT0BQa7oYGKXQQsU-XfqvoxfDyijehJO3Q@mail.gmail.com>
In-Reply-To: <YXcC8jQbFsaqYN2M@coredump.intra.peff.net>

A few quick updates to some of the questions:

On Mon, Oct 25, 2021 at 12:18 PM Jeff King <peff@peff.net> wrote:

Show 21 quoted lines

>
> On Mon, Oct 25, 2021 at 12:02:38PM -0700, Bryan Turner wrote:
>
> > I'm working with some users trying to reconcile an odd mismatch
> > observed in some Git output.
> >
> > Running an ls-tree for a branch and path, limited to a single pattern
> > within, shows this:
> > /usr/bin/git ls-tree -z refs/heads/develop:path/to/parent – file
> > 100644 blob 4c8d566ed80a1554a059b97f7cd533a55bbd2ea8    file
> >
> > If we then run cat-file --batch-check, though, we see this:
> > echo 'refs/heads/develop
> > refs/heads/develop:path/to/parent/file' | /usr/bin/git cat-file --batch-check
> > 28a05ce2e3079afcb32e4f1777b42971d7933a91 commit 259
> > cc10f4b278086325aab2f95df97c807c7c6cd75e commit 330
>
> That's definitely odd. Some things I'd try:
>
>   - do other versions of cat-file behave differently (i.e., is it a
>     regression)?

They're using Git 2.32 built from source on Ubuntu 20.04. I may see if they can reinstall the 2.25.1 from focal's standard repositories and see if it reproduces the issue. That said, they may not be able/willing to do it.

Show 5 quoted lines

>
>   - what does "git rev-parse refs/heads/develop:path/to/parent/file"
>     say? If it comes up with 4c8d566ed80, then the problem is cat-file
>     specific. If not, then it's a problem in the name resolution
>     routines.

$ /usr/bin/git rev-parse refs/heads/develop 28a05ce2e3079afcb32e4f1777b42971d7933a91 $ /usr/bin/git rev-parse refs/heads/develop:path/to/parent/file cc10f4b278086325aab2f95df97c807c7c6cd75e

So it looks like rev-parse and cat-file --batch-check both exhibit the same behavior.

I also had them expand their cat-file --batch-check to include another file in the same "path/to/parent" directory: $ echo 'refs/heads/develop refs/heads/develop:path/to/parent/sibling refs/heads/develop:path/to/parent/file' | /usr/bin/git cat-file --batch-check 28a05ce2e3079afcb32e4f1777b42971d7933a91 commit 259 2bfe7b4b7c7cdeb9653801d99b65dfefe5780dda blob 897 cc10f4b278086325aab2f95df97c807c7c6cd75e commit 330

So the "sibling" file in the same directory comes out as a "blob", as expected.

They also ran an ls-tree for the directory without any globs: # /usr/bin/git ls-tree refs/heads/develop:path/to/parent 100644 blob 2bfe7b4b7c7cdeb9653801d99b65dfefe5780dda sibling 100644 blob 4c8d566ed80a1554a059b97f7cd533a55bbd2ea8 file

For "sibling" the blob's ID matches what cat-file --batch-check shows, as I'd expect. There are several other tree entries, one "tree" and the rest "blob", that I've omitted for brevity. All of their modes look normal.

I also had them check ls-tree for some parent levels: $ /usr/bin/git ls-tree refs/heads/develop:path -- to 040000 tree 5244cd18e3d9de9002bdfcd18e173ca55c035084 to $ /usr/bin/git ls-tree refs/heads/develop:path/to -- parent 040000 tree 2847dc49d79e8d66040047a9dd61376115bf8829 parent

Nothing out of the ordinary to my eye.

Show 5 quoted lines

>
>   - likewise, what does "git cat-file -t cc10f4b27808" say? I'd expect
>     it to really be a commit (a bug in batch-check's formatting routines
>     could show the wrong object, but I'd expect the oid to at least
>     match what ls-tree showed).

$ /usr/bin/git cat-file -t cc10f4b278086325aab2f95df97c807c7c6cd75e commit

>
>   - Is there anything odd about the tree? E.g., duplicate entries, out
>     of order entries, etc? Examining "ls-tree" output might help, but
>     "git fsck" should also note any irregularities.

$ /usr/bin/git fsck --no-dangling Checking object directories: 100% (256/256), done. Checking object directories: 100% (256/256), done. Checking objects: 100% (122888/122888), done.

There's one alternate. No warnings, though.

Show 5 quoted lines

>
> After that, I'd probably start running "cat-file --batch-check" through
> a debugger. I know you said you don't have access to the repository, but
> perhaps whoever does might be willing to run it through "fast-export
> --anonymize" and see if the bug persists?

I've asked them to double-check whether they can provide me with the repository, or with an anonymized copy. At this point, it feels like there's not a lot more I can do/check without access to data that reproduces the issue so I can attach a debugger.

Thanks again, Bryan