A few quick updates to some of the questions: On Mon, Oct 25, 2021 at 12:18 PM Jeff King <peff@xxxxxxxx> 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
