On 8/11/25 1:54 AM, Patrick Steinhardt wrote:
Thanks to you and Junio for looking at this.
I agree that this shouldn't be considered a high priority
bug.
Do you agree that the below should be what I see?
# I would have expected:
hint: 78981922613b2afb6025042ff6bd878ac1994e85 blob
hint: 78981922613b2afb6025042ff6bd878ac1994e86 blob
The reason I'm doing this is because, just for fun, I'm
trying to implement the disambiguation code in Go, and
I needed a test case.
Hm. I think the problem here is that you intentfully corrupt the
repository by copying the blob to a different name.
I didn't intentionally corrupt the repository but I couldn't think
of any other way to do what I needed to do.
How would you have done this?
I'm not really sure that this is something that we need to fix -- the
repository is corrupt, and git-fsck(1) should tell you so.
Here's what git-fsck said:
% git fsck
Checking ref database: 100% (1/1), done.
error: ee1a0d672b283dc03c94a266647e505ad340dc29: hash-path mismatch,
found at: .git/objects/ee/1a0d672b283dc03c94a266647e505ad340dc30
Checking object directories: 100% (256/256), done.
dangling tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
dangling tree d4607c312181a2fdbb66e8accb5b006156b6b733
Did you hit any real world scenario where this has happened
> in the wild without intentfully corrupting the repository?
No
> Or given that you explicitly mention Git 2.50, has the behaviour
> changed recently?
I mentioned Git 2.50 because I wanted to write a useful bug report.
I have no idea if the behavior has changed.
Thanks for your work.
Jon
