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

[Bryan Turner <bturner@atlassian.com>]

A few quick updates to some of the questions:

On Mon, Oct 25, 2021 at 12:18 PM Jeff King <peff@peff.net> wrote:
>
> 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.

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

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

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