Re: [PATCH] abbrev: allow extending beyond 20 chars to disambiguate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes:
>
>> On 2025-08-11 at 15:26:32, Junio C Hamano wrote:
>>> When you have two or more objects with object names that share more
>>> than half the length of the hash algorithm in use (e.g. 10 bytes for
>>> SHA-1 that produces 20-byte/160-bit hash), find_unique_abbrev()
>>> fails to show disambiguation.
>>
>> Is this really the case?  
>
> What I wrote in the above is correct.

Sorry, I meant "incorrect".  And using GIT_MAX_HEXSZ will break the
abbreviation system rather badly.  It has to be the length of the
hash that is being used.

>
>> If the restriction is due to using
>> GIT_MAX_RAWSZ instead of GIT_MAX_HEXSZ, then that's 32 vs. 64 in our
>> modern codebase.
>
> The above numbers are correct but irrelevant ;-).
>
> The thing is, the offending commit changed from 40-bytes
> (GIT_SHA1_HEXSZ) to 32-bytes (GIT_MAX_RAWSZ).  Plase see v2 patch.
>
> Thanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux