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

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

 





On 8/11/25 2:17 PM, brian m. carlson wrote:

To see how many leading letters of a given full object name is
sufficiently unambiguous, the algorithm starts from a initial
length, guessed based on the estimated number of objects in the
repository, and see if another object that shares the prefix, and
keeps extending the abbreviation.  The loop stops at GIT_MAX_RAWSZ,
which is counted as the number of bytes, since 5b20ace6 (sha1_name:
unroll len loop in find_unique_abbrev_r(), 2017-10-08); before that
change, it extended up to GIT_MAX_HEXSZ, which is the correct limit
because the loop is adding one output letter per iteration.

I'm new to all this but the way I did it is much simpler.
What I did was to check all the files in the appropriate
object store directory (e.g. .git/objects/XX, where XX are
the first 2 letters of the object given on the command line.
If any of the filenames in that directory start with the
string given on the command line, minus the first 2 letters,
then that's a match. If more than one filename matches then
that's ambiguous.

What's wrong with this approach?

Jon





[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