git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: git@vger.kernel.org,
	 Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Wing Huang <huangsen365@gmail.com>
Subject: Re: [PATCH 1/6] t0018: switch default branch name to main
Date: Thu, 28 Aug 2025 09:49:35 -0700	[thread overview]
Message-ID: <xmqqbjnzwfvk.fsf@gitster.g> (raw)
In-Reply-To: <b6b60e6b-c06d-4dc6-8722-b53736f8b059@gmail.com> (Phillip Wood's message of "Thu, 28 Aug 2025 15:00:08 +0100")

Phillip Wood <phillip.wood123@gmail.com> 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.

  reply	other threads:[~2025-08-28 16:49 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-27 15:24 [PATCH 0/6] breaking changes: switch default initial branch name to "main" Phillip Wood
2025-08-27 15:24 ` [PATCH 1/6] t0018: switch default branch name to main Phillip Wood
2025-08-27 17:21   ` Junio C Hamano
2025-08-28 14:00     ` Phillip Wood
2025-08-28 16:49       ` Junio C Hamano [this message]
2025-08-28 21:31         ` brian m. carlson
2025-08-27 15:24 ` [PATCH 2/6] t4013: " Phillip Wood
2025-08-27 15:24 ` [PATCH 3/6] t9902: " Phillip Wood
2025-08-27 15:24 ` [PATCH 4/6] t0613: stop setting default initial branch Phillip Wood
2025-08-27 17:30   ` Junio C Hamano
2025-08-27 15:24 ` [PATCH 5/6] t1403: remove dependency on GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME Phillip Wood
2025-08-27 15:24 ` [PATCH 6/6] breaking-changes: switch default branch to main Phillip Wood
2025-08-27 18:41   ` Junio C Hamano
2025-09-02 11:36   ` Patrick Steinhardt
2025-09-02 15:13     ` Phillip Wood
2025-09-03  4:44       ` Patrick Steinhardt
2025-09-03  9:54         ` Phillip Wood
2025-09-03 11:51           ` Patrick Steinhardt
2025-09-03 18:40           ` Junio C Hamano
2025-09-04  7:09             ` Patrick Steinhardt
2025-09-04 13:30               ` Phillip Wood
2025-09-05  6:07                 ` Patrick Steinhardt
2025-09-04 13:27             ` Phillip Wood
2025-08-28 13:12 ` [PATCH 0/6] breaking changes: switch default initial branch name to "main" Johannes Schindelin
2025-09-04 13:21 ` [PATCH v2 0/4] " Phillip Wood
2025-09-04 13:21   ` [PATCH v2 1/4] breaking-changes: switch default branch to main Phillip Wood
2025-09-04 17:40     ` Junio C Hamano
2025-09-05 10:06       ` Phillip Wood
2025-09-05 15:04         ` Junio C Hamano
2025-09-04 13:21   ` [PATCH v2 2/4] t4013: switch default branch name " Phillip Wood
2025-09-04 13:21   ` [PATCH v2 3/4] t9902: " Phillip Wood
2025-09-04 18:27     ` Junio C Hamano
2025-09-05 10:07       ` Phillip Wood
2025-09-05 12:14     ` Patrick Steinhardt
2025-09-09  9:12       ` Phillip Wood
2025-09-04 13:21   ` [PATCH v2 4/4] t0613: stop setting default initial branch Phillip Wood
2025-09-04 18:35     ` Junio C Hamano
2025-09-05 10:09       ` Phillip Wood
2025-09-04 17:03   ` [PATCH v2 0/4] breaking changes: switch default initial branch name to "main" Junio C Hamano
2025-09-04 18:47     ` Phillip Wood
2025-09-10 15:28 ` [PATCH v3 " Phillip Wood
2025-09-10 15:29   ` [PATCH v3 1/4] breaking-changes: switch default branch to main Phillip Wood
2025-09-10 15:29   ` [PATCH v3 2/4] t4013: switch default branch name " Phillip Wood
2025-09-10 15:29   ` [PATCH v3 3/4] t9902: " Phillip Wood
2025-09-10 15:29   ` [PATCH v3 4/4] t0613: stop setting default initial branch Phillip Wood
2025-09-10 20:41   ` [PATCH v3 0/4] breaking changes: switch default initial branch name to "main" Junio C Hamano
2025-09-17  9:22     ` Junio C Hamano
2025-09-17 12:02       ` Kristoffer Haugsbakk
2025-09-17 15:02         ` Junio C Hamano
2025-09-17 14:53       ` Phillip Wood
2025-09-17 15:21         ` Junio C Hamano
2025-09-17 16:16           ` Junio C Hamano
2025-09-18 15:06             ` Phillip Wood
2025-09-17 16:18   ` [PATCH v2 5/4] initial branch: give hints after switching the default name Junio C Hamano
2025-09-18 15:06     ` Phillip Wood
2025-09-18 18:42       ` Junio C Hamano

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=xmqqbjnzwfvk.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=huangsen365@gmail.com \
    --cc=phillip.wood123@gmail.com \
    /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).