Re: [PATCH 1/6] t0018: switch default branch name to main

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 28, 2025, 16:49 UTC
Message-ID: <xmqqbjnzwfvk.fsf@gitster.g>
In-Reply-To: <b6b60e6b-c06d-4dc6-8722-b53736f8b059@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 12 quoted lines

>>> These tests use "trunk" as the default branch name but the exact
>>> name of the branch is incidental to testing if the advice message
>>> includes it. ...
>> Would't we be better prepared for a future where advice messages may
>> start including the current branch name, though, if we made sure we
>> are on the branch whose name is known?
>
> The advice message does include the current branch name, that's why
> the test needs to be updated when we change that name from "trunk" to
> "main". The sentence above is trying to say that it does not matter
> what that name is, we just need to check it appears in the advice
> message.

That makes 100% sense.

> I could see an argument for the tests not depending on git's
> default branch name if it changed frequently but realistically we're
> unlikely to change in again in the near future.

A test that automatically adjusts to the then-current default so that we do not have to worry about what it is is much better than a test that needs constant maintenance every 10 years. A test that uses one fixed name is slightly worse than auto-adjusting one, but is still far better as it is maintenance-free.

Hardwiring a name the test uses does have one distinct advantage, i.e., it serves as a documentation that the test vector depends on the branch name, making it clear where the thing that the test expects comes from.

> If we did use a different name in the tests it is just as likely
> to cause objections and need to be changed as git's default name
> so I'm not sure it gains us much.

I do not quite understand. Do you mean in 20 years some animal rights activists object that 'trunk' is offensive to elephants and we will be forced to change? As I do not see the difference between 'main' and 'trunk' about how likely either of them get such complaint against, I can live with hardwiring the branch name used in the test 'main', but then 'trunk' would equally work well, so unless there are other things the patch changes, I do not quite see much point in this patch.

[Footnote]

By the way, I do appreciate the "let's switch the default as promised at the major version boundary", the primary theme of this topic. I think we have done enough prep work to ensure that the result would work without disruption with existing projects by ensuring that (1) existing user repositories can keep working, as this is only about the initial branch name, (2) existing project repositories cloned anew will keep working as before, as we follow what the upstream does.

One thing that is missing is probably a way to remotely create a symref (or repoint one). As it would break existing users if an upstream suddenly switches its 'master' to 'main', the second best thing to do is to ensure that they always point at the same commit, and the natural way to do so is to

    $ git symbolic-ref refs/heads/main refs/heads/master

but we cannot do so remotely. I've been doing the third best thing since late November 2021, which is to push to both at the same time, which is ugly but https://git.kernel.org/pub/scm/git/git.git/ and other mirrors may tell you that both are available.

All other mirrors do not have CI attached to them, and they have been running with both 'main' and 'master' pointing at the same commit for quite some time, but https://github.com/git/git/ does not have 'main'; I attempted back when I arranged to do the "push to both" back in November 2021, but it caused two CI jobs on 'master' and 'main' run on the identical sources simultanously, wasting resources, every time the topics graduated, so I stopped doing so.

Perhaps tweaking the .github/workflows/main.yml file a bit and explicitly excluding either one of these two identical branches would be what it takes, but it would probably be a multi-step process, to (1) tell it to ignore the 'main' branch, (2) start pushing to 'main' in addition to 'master', and then finally (3) flip the CI config to tell it to ignore the 'master' branch instead.