"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes:
> On 2025-06-30 at 13:46:35, Karthik Nayak wrote:
>> I can see few solutions overall (including the one you suggested).
>>
>> One solution is to drop duplicates in case insensitive systems, this is
>> the shortest and easiest fix for now.
>>
>> Perhaps something like (untested back of the hand code):
>>
>> diff --git a/builtin/fetch.c b/builtin/fetch.c
>> index cc0a3deb61..bc79d74b82 100644
>> --- a/builtin/fetch.c
>> +++ b/builtin/fetch.c
>> @@ -1352,10 +1352,16 @@ static int prune_refs(struct display_state
>> *display_state,
>> goto cleanup;
>> }
>> } else {
>> + const char *prev;
>> struct string_list refnames = STRING_LIST_INIT_NODUP;
>>
>> - for (ref = stale_refs; ref; ref = ref->next)
>> + for (ref = stale_refs; ref; ref = ref->next) {
>> + if (ignore_case && prev && !strcasecmp(ref->next, prev))
>> + continue;
>> +
>> string_list_append(&refnames, ref->name);
>> + prev = ref->name;
>> + }
>
> This won't work in the general case, since the two refs that match case
> insensitively aren't guaranteed to be adjacent. For instance:
>
> refs/heads/AAAA
> refs/heads/AAAB
> refs/heads/aaaa
> refs/heads/aaab
>
> They'll be in the above order for a bytewise comparison, but the
> matching entries won't be adjacent in the list.
>
Indeed. Good catch, this wouldn't work! I guess you'd have to use a
hashmap in that case, I think that is what Jayatheerth also mentioned in
his reply.
> Another option is for users on case-insensitive systems to use reftable,
> which won't have the same problems as the file-based backend and will
> preserve case properly.
Yes, that's always recommended! But until we start marking the files
backend as deprecated, we do have to plug this bug.
> --
> brian m. carlson (they/them)
> Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
