git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Matt McCutchen <matt@mattmccutchen.net>
To: git@vger.kernel.org
Subject: Renaming the "master" branch without breaking existing clones
Date: Mon, 03 Aug 2020 08:15:58 -0400	[thread overview]
Message-ID: <ec960483f5008e9948271c678d51876920ab62c9.camel@mattmccutchen.net> (raw)

[Apologies if there is an existing thread about this; I searched hard
and wasn't able to find one.]

I've just become aware of the discussion that the name of the "master"
branch should be changed.  I'm not taking a position on this now, but
it seems enough people want to make the change that we should resolve
the technical problems, of which I see several:

1. Allowing tools to be configured to change the default name for new
repositories.  Work on this appears to be well underway with no
fundamental obstacles.

2. Renaming the branch in existing repositories.  I've seen a number of
guides for how to do it in the central repository, and they all seem to
expect users with existing clones to manually reconfigure them all at
once.  To me, that amount of disruption would be unacceptable for
central repositories I'm in charge of (admittedly few with few users,
so I imagine some will argue I should leave it to the bigger players to
complain about this), whether or not one believes that the social
justice benefit of changing the branch name in personal clones merits
the work at all.  I found only one guide that addresses this problem:

https://github.com/chancancode/branch-rename#gradual-migration

It includes a procedure to mirror the "master" branch from the new
default branch so that readers of the central repository don't need to
reconfigure anything.  Writers need to be reconfigured.  That seems
reasonable to me.

Unfortunately, the mirroring method seems to be specific to the
repository hosting service being used.  If services supported standard
git hooks, that would probably work, but I can understand if the
services don't because it's unwieldy to execute shell scripts without
introducing security risks.

This guide seems well thought out to me on a first read, but I suspect
there may be aspects that could benefit from a lot more scrutiny from
experts, and I want to encourage them to provide it.

3. Ensuring that tools detect the default branch of a given repository
in an appropriate way rather than assuming "master".  Where applicable,
the remote HEAD symref is probably the best thing to use.  See for
example:

https://github.com/chancancode/branch-rename#packages-considerations

This category would also include git's feature of leaving the target
branch name out of the merge message, for example.  I believe the
necessary work on git itself is underway; other tools may lag.

For read-only tools, this mainly matters for central repositories that
eventually delete their "master" branch, which may not be all of them,
but again, it sounds like there will be enough such repositories that
we should consider the problem.  I don't see any fundamental obstacle,
but this may benefit from more scrutiny as well.

I'm aware that asking others to do work is often poorly received.  This
message is just to get people's attention so they can do the work if
they wish.

Thanks for reading.

Matt


             reply	other threads:[~2020-08-03 12:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 12:15 Matt McCutchen [this message]
2020-08-03 16:00 ` Taylor Blau
2020-08-03 16:19   ` Junio C Hamano
2020-08-03 16:39     ` Taylor Blau
2020-08-03 19:40   ` Jeff King
2020-08-03 20:40     ` Junio C Hamano
2020-08-03 20:45     ` Jeff King
2020-08-03 21:02       ` Junio C Hamano
2020-08-03 21:11         ` Jeff King
2020-08-03 21:38           ` Junio C Hamano
2020-08-04  0:37     ` Matt McCutchen
2020-08-04  0:43   ` Matt McCutchen
2020-08-03 16:14 ` Junio C Hamano
2020-08-03 17:41   ` Matt McCutchen
2020-08-03 18:20   ` Kaartic Sivaraam
2020-08-03 18:47     ` Junio C Hamano
2020-08-04  8:50       ` Kaartic Sivaraam

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ec960483f5008e9948271c678d51876920ab62c9.camel@mattmccutchen.net \
    --to=matt@mattmccutchen.net \
    --cc=git@vger.kernel.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.
Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).