Jon Forrest <nobozo@xxxxxxxxx> writes: > % 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 Fun. I do not think disambiguation code inspects object validity to filter out invalid one when computing the shortened object name when giving hints, so one of these two being a corrupt object should not have anything to do with this outcome. Perhaps something like this would help? object-name.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git c/object-name.c w/object-name.c index 11aa0e6afc..13e8a4e47d 100644 --- c/object-name.c +++ w/object-name.c @@ -704,7 +704,7 @@ static int extend_abbrev_len(const struct object_id *oid, void *cb_data) while (mad->hex[i] && mad->hex[i] == get_hex_char_from_oid(oid, i)) i++; - if (i < GIT_MAX_RAWSZ && i >= mad->cur_len) + if (i < GIT_MAX_HEXSZ && i >= mad->cur_len) mad->cur_len = i + 1; return 0;
