On Sun, Aug 10, 2025 at 07:52:42AM -0700, Jon Forrest wrote: > (Sorry if you see this more than once) > > I'm using 'git cat-file' to show the example. This is probably not a > command-specific problem. > > The problem is that using a deliberately ambiguous object ID produces > surprising output. This is a minor issue. > > % git --version > git version 2.50.GIT > % uname -a > Linux fedora 6.15.9-201.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Aug 2 > 11:37:34 UTC 2025 x86_64 GNU/Linux > > % git init > > # depending on where you run the test, might not be necessary > % git config --global --add safe.directory /tmp > > Initialized empty Git repository in /tmp/.git/ > % echo a > a.txt > % git add a.txt > % git ls-files -s > 100644 78981922613b2afb6025042ff6bd878ac1994e85 0 a.txt > % git cat-file -t 78981922613b2afb6025042ff6bd878ac1994e85 > blob > > # All is well so far. > > % pushd .git/objects/78 > % ls > 981922613b2afb6025042ff6bd878ac1994e85 > # create a new file with the same name as the file that already exists, > # except change the final letter to something else. > % cp 981922613b2afb6025042ff6bd878ac1994e85 > 981922613b2afb6025042ff6bd878ac1994e86 > % ls > 981922613b2afb6025042ff6bd878ac1994e85 > 981922613b2afb6025042ff6bd878ac1994e86 > % popd > # use an ambiguous SHA1 prefix > # why does the next command produce two identical hints, both of which > # are incorrect? > % git cat-file -t 78981922613b2afb6025042ff6bd878ac1994e8 > error: short object ID 78981922613b2afb6025042ff6bd878ac1994e8 is ambiguous > # this is correct > hint: The candidates are: > hint: 7898192 blob > hint: 7898192 blob > fatal: Not a valid object name 78981922613b2afb6025042ff6bd878ac1994e8 > # I would have expected: > hint: 78981922613b2afb6025042ff6bd878ac1994e85 blob > hint: 78981922613b2afb6025042ff6bd878ac1994e86 blob > # using the supplied hint doesn't work, which is no surprise > % git cat-file -t 7898192 > fatal: Not a valid object name 7898192 Hm. I think the problem here is that you intentfully corrupt the repository by copying the blob to a different name. As the object contents itself remain the same though, and as the object ID is computed by hashing the object, looking up that object would ultimately lead to the original object ID. The consequence is that `show_ambiguous_object()` becomes confused. It _looks_ like the object name is ambiguous, but it ultimately isn't because both names refer to the same underlying object. We then use `repo_find_unique_abbrev()` to shorten the printed object IDs that are printed in the error message, but given that those are really the same object we abbreviate them to the same shortened object ID. 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. Did you hit any real world scenario where this has happened in the wild without intentfully corrupting the repository? Or given that you explicitly mention Git 2.50, has the behaviour changed recently? Thanks! Patrick
