Re: [PATCH] rename default branch from 'master' to 'main' in refs and test scripts
Hi Peff
On 26/08/2025 12:12, Jeff King wrote:
Show 19 quoted lines
> 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
Show 14 quoted lines
>>> @@ -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
>