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