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

[Bryan Turner <bturner@atlassian.com>]

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

I don't have that specific data, but one thing I do know is that
cat-file -p prints commit contents:

/usr/bin/git cat-file -p refs/heads/develop:path/to/parent/file
tree c378146c918c05794e5fb1d1f6986c81ca866326
parent 6cb6016c78c4c963311ca82fc53764141b0d3bdd
author ...
committer ...

<Commit message starts here>

One other observation. I threw
cc10f4b278086325aab2f95df97c807c7c6cd75e into Github's search, on a
lark, since so much open source is there, and it actually finds that
commit in multiple repositories[1][2][3]

[1] https://github.com/bitcoin-sv/bitcoin-sv/commit/cc10f4b278086325aab2f95df97c807c7c6cd75e
[2] https://github.com/fakecoinbase/bitcoin-svslashbitcoin-sv/commit/cc10f4b278086325aab2f95df97c807c7c6cd75e
[3] https://github.com/TuringBitchain/TuringBitchain/commit/cc10f4b278086325aab2f95df97c807c7c6cd75e

None of those repositories has a branch named "develop", and the
"file" I've obscured here is not present in any of them, so while
there is clearly some ancestry in this repository with open source
roots, it's evolved since then. Experimenting with some of the
"nearby" files that are present in those public repositories, I have
not been able to reproduce the issue in any of them.

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

I've sent some further commands, based on your suggestions, to the users.

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

fast-export --anonymize might be a way forward. Thanks for suggesting
it (I always forget about it); I've mentioned it to the users.

Thanks Jeff; I appreciate your time/insights!

Best regards,
Bryan Turner