Subject: Re: [PATCH] rename default branch from 'master' to 'main' in refs and test scripts

From: Phillip Wood <[email-masked]>
Date: Wed, 27 Aug 2025 14:26:44 +0100

Hi Peff

On 26/08/2025 12:12, Jeff King wrote:
> On Tue, Aug 26, 2025 at 10:58:55AM +0100, Phillip Wood wrote:
> 
>>>        * remote.c: Update fallback branch name for remote operations
>>
>> I think we want to keep the fallback to "master" but check for "main" first.
>> Otherwise we'll stop finding the default branch where the remote is still
>> using master.
> 
> I'm not sure we need to change anything there. Modern Git will generally
> report the name of the branch pointed to by HEAD back to the client
> (using either a symref capability in protocol v0 or the symref extension
> to the ls-refs list in v2). So the fallback would be needed only for
> very old servers, in which case "master" is probably a better guess.
> 
> IIRC, there are cases where v0 does not report the HEAD value when it
> points to an unborn branch (and while I'd expect most Git servers to
> always support v2 these days, sometimes the protocol upgrade fails due
> to things like ssh blocking the GIT_PROTOCOL variable). But I don't
> think that would affect the fallback code:

Thanks for clarifying that

Phillip

>>> @@ -2379,7 +2379,7 @@ struct ref *guess_remote_head(const struct ref *head,
>>>    			return copy_ref(r);
>>>    		/* Fall back to the hard-coded historical default */
>>> -		r = find_ref_by_name(refs, "refs/heads/master");
>>> +		r = find_ref_by_name(refs, "refs/heads/main");
>>>    		if (r && oideq(&r->old_oid, &head->old_oid))
>>>    			return copy_ref(r);
> 
> since it is only about looking for the matching branch name, and not the
> unborn case.
> 
> If we truly have an unborn HEAD on a very old server (with no protocol
> support), I think we just end up without checking anything out, which
> means HEAD would default to whatever the local client default is.

I just tried cloning a repository with an unborn head and the clone >
> -Peff