Derrick Stolee <stolee@xxxxxxxxx> writes:
> On 10/4/2017 2:07 AM, Junio C Hamano wrote:
>> Derrick Stolee <dstolee@xxxxxxxxxxxxx> writes:
>>
>>> - exists = has_sha1_file(sha1);
>>> - while (len < GIT_SHA1_HEXSZ) {
>>> - struct object_id oid_ret;
>>> - status = get_short_oid(hex, len, &oid_ret, GET_OID_QUIETLY);
>>> - if (exists
>>> - ? !status
>>> - : status == SHORT_NAME_NOT_FOUND) {
>>> - hex[len] = 0;
>>> - return len;
>>> - }
>>> - len++;
>>> - }
>>> - return len;
>> The "always_call_fn" thing is a big sledgehammer that overrides
>> everything else in update_candidates(). It bypasses the careful
>> machinery set up to avoid having to open ambiguous object to learn
>> their types as much as possible. One narrow exception when it is OK
>> to use is if we never limit our candidates with type.
>
> I do not modify get_short_oid, which uses these advanced options,
> depending on the flags given. find_unique_abbrev_r() does not use
> these advanced options.
It is true that the function no longer even calls get_short_oid().
When it called get_short_oid() before this patch, it not pass "I
want to favor committish" in the old code, as we can see in the
above removed code. In get_short_oid(), ds.fn would have been set
to default_disambigutate_hint, and that would have been used in the
update_candidates() function.
Now, unless the user has core.disambiguate configuration set, this
"default" thing becomes NULL, so overriding ds.fn like this patch
does and bypass major parts of update_candidates() is probably fine.
After all, update_candidates() wouldn't have inspected the object
types and made the candidate management anyway with ds.fn set to
NULL.
But having the configuration set would mean that the user wants to
set default_disambigutate_hint to some non-default value, e.g.
telling us to find disambiguation only among committishes; the patch
however overrides ds.fn and essentially makes the code ignore it
altogether, no? That change in behaviour was what I was wondering
about.
