From: Phillip Wood <phillip.wood123@gmail.com>
To: Jeff King <peff@peff.net>, phillip.wood@dunelm.org.uk
Cc: Wing Huang via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Wing Huang <huangsen365@gmail.com>,
Andreas Schwab <schwab@linux-m68k.org>
Subject: Re: [PATCH] rename default branch from 'master' to 'main' in refs and test scripts
Date: Wed, 27 Aug 2025 14:26:44 +0100 [thread overview]
Message-ID: <cf89ccda-442f-4b98-b30d-93f708e64133@gmail.com> (raw)
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
>
next prev parent reply other threads:[~2025-08-27 13:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 4:52 [PATCH] rename default branch from 'master' to 'main' in refs and test scripts Wing Huang via GitGitGadget
2025-08-26 9:14 ` Andreas Schwab
2025-08-26 9:58 ` Phillip Wood
2025-08-26 11:12 ` Jeff King
2025-08-27 13:26 ` Phillip Wood [this message]
2025-08-26 11:20 ` Phillip Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cf89ccda-442f-4b98-b30d-93f708e64133@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=huangsen365@gmail.com \
--cc=peff@peff.net \
--cc=phillip.wood@dunelm.org.uk \
--cc=schwab@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).