git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Matt McCutchen <matt@mattmccutchen.net>
Cc: git@vger.kernel.org
Subject: Re: Renaming the "master" branch without breaking existing clones
Date: Mon, 3 Aug 2020 12:00:51 -0400	[thread overview]
Message-ID: <20200803160051.GA50799@syl.lan> (raw)
In-Reply-To: <ec960483f5008e9948271c678d51876920ab62c9.camel@mattmccutchen.net>

On Mon, Aug 03, 2020 at 08:15:58AM -0400, Matt McCutchen wrote:
> [Apologies if there is an existing thread about this; I searched hard
> and wasn't able to find one.]

Perhaps this isn't exactly what you're going for, but I raised a similar
point a couple of months ago:

  https://lore.kernel.org/git/20200611010720.GA21728@syl.local/

> 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.

Yes, this was released with 2.28. Users can set 'init.defaultBranch' and
have 'git init' respect it when creating the first branch in a new
repository.

> 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.

This is more-or-less what I was proposing in the message that I linked
above. Maybe a more solidified proposal might look something as follows:

  - We could introduce a mechanism to mark certain refs as aliases to
    other refs. For example, a remote might publish its
    'refs/heads/master' as an alias to 'refs/heads/main', so that any
    reads or writes to the former get applied to the latter
    transparently.

  - A ref alias can be annotated to say "I am a transition ref alias",
    i.e., that clients should be taught to rename their copy of 'master'
    to 'main' (and update remote-tracking refs accordingly).

  - Clients can enable/disable automatic branch renaming.

I am a little uncomfortable with the idea that a 'git pull' would modify
'refs/{heads,tags}' in addition to 'refs/remotes'. We expect that 'git
pull' will touch remote refs, and we sometimes expect it to update
non-remote refs when they are remote-tracking.

So, I think that you'd only want to let ref aliases automatically
rename remote tracking references, and only if the user opted in to
automatic renaming.

I'm not sure, though. I haven't thought about it too much.

> 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 less qualified to talk about what's going on here, but my
understanding is that providers and tool-makers are quite aware of this.

> 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.

Thanks for your concern.

> Matt

Thanks,
Taylor

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

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 12:15 Matt McCutchen
2020-08-03 16:00 ` Taylor Blau [this message]
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=20200803160051.GA50799@syl.lan \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=matt@mattmccutchen.net \
    /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).