From: Phillip Wood Date: Wed, 27 Aug 2025 13:26:44 GMT Subject: Re: [PATCH] rename default branch from 'master' to 'main' in refs and test scripts Message-ID: In-Reply-To: <20250826111234.GA1925107@coredump.intra.peff.net> 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 >