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