Re: [PATCH] abbrev: allow extending beyond 20 chars to disambiguate
- From
Jon Forrest <nobozo@gmail.com>
- Date
- Aug 12, 2025, 15:26 UTC
- Message-ID
- <e463481d-b6a6-4928-86e1-63677f5a88b2@gmail.com>
- In-Reply-To
- <aJpd2MYMWgEoxQWi@fruit.crustytoothpaste.net>
On 8/11/25 2:17 PM, brian m. carlson wrote:
Show 9 quoted lines
>> 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