Phillip Wood <phillip.wood123@xxxxxxxxx> writes:
>>> 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.
