Renaming the "master" branch without breaking existing clones

Renaming the "master" branch without breaking existing clones

[Matt McCutchen]

[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

Re: Renaming the "master" branch without breaking existing clones

[Taylor Blau]

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

Re: Renaming the "master" branch without breaking existing clones

[Junio C Hamano]

Matt McCutchen <matt@mattmccutchen.net> writes:

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

I wonder if that would work well.  Your refs/remotes/origin/HEAD is
designed to be tweaked by you to indicate which remote branch is of
interest to you to your local Git.  Those who are interested in
following along 'maint' can update refs/remotes/origin/HEAD to point
at refs/remotes/origin/maint in their clone of this project, and
they can say "git fetch origin && git log origin" to see the history
leading to the tip of 'maint' in my repository.

At least, that is how it is designed to work.  So "compare local
refs/remotes/origin/HEAD and what 'git ls-remote origin' sees where
they point at with their HEAD---if they are different, ours have old
name and theirs have new name" is not a good heuristics.

If we wanted to do this properly, I'd imagine we'd need to add a
mechanism for repositories to convey "this branch that used to exist
got renamed to this other name", not specifically for any "special"
branch name (like 'master').  If we plan to never allow reusing the
old and banned name, it probably is enough to turn the old name into
a symbolic ref that points at the new name, e.g. in my repository

    $ git update-ref refs/heads/seen refs/heads/pu
    $ git update-ref -d refs/heads/pu
    $ git symbolic-ref refs/heads/pu refs/heads/seen

which would create a symbolic reference 'pu' that points at 'seen'
to say "pu used to exist but it is now seen".

But that would not work well, as we must allow reusing the old name,
as the primary point of renaming 'pu' to 'seen' in this project was
so that we can accept topics from contributors whose anglicized name
has 'p' and 'u' in capital letters as pu/$topicname branches.  Having
a symbolic ref 'pu' would defeat that plan.

So perhaps we'd need to emply the usual trick to have a blob on
"meta" ref, say "refs/meta/ref-rename" might contain multiple tuples
that tells the receiving end about each moved ref:

    - the name of the 'old' ref (e.g. 'refs/heads/pu')
    - the name of the 'new' ref (e.g. 'refs/heads/seen')
    - (optional) when the 'move' happened

As it does not make much sense to perform the local side migration
silently and behind the user's back while the user is actively
working in the repository, it is likely that the migration
instruction would be written as a "perform this when it is
convenient for you" one-time event.  It may start by fetching the
"meta/ref-rename" blob and perform "what to do when remote ref X is
moved to remote ref Y" procedure.

That procedure should also be executable offline, without the remote
end publishing the "meta/ref-rename" data.  If you know your upstream
has changed 'pu' to 'seen', you should be able to do

    $ git ref-migration-helper refs/remotes/origin/pu refs/remotes/origin/seen

so that many things related to these names are changed (and that is
the most complex part---compared to that, conveying what rename the
remote end did to the local Git is much simpler), including

    - renaming the remote-tracking branches (obvious)

    - reconfiguring local branches that have their upstream branch
      set to the 'old' remote-tracking branch to make their upstream
      branch to the 'new' remote-tracking branch.

There may be others.

Re: Renaming the "master" branch without breaking existing clones

[Junio C Hamano]

Taylor Blau <me@ttaylorr.com> writes:

> I am a little uncomfortable with the idea that a 'git pull' would modify
> 'refs/{heads,tags}' in addition to 'refs/remotes'.

Those who want to rename their own branches should be allowed to do
so easily when it is convenient for them to do so, whether the
reason for renaming their local branch is because their upstream
renamed the branches they are interested in and have good reasons to
use the same name, or because they made a typo when they created
their local brnach, but I do not think renaming the local branch
should be done automatically.

Re: Renaming the "master" branch without breaking existing clones

[Taylor Blau]

On Mon, Aug 03, 2020 at 09:19:52AM -0700, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
>
> > I am a little uncomfortable with the idea that a 'git pull' would modify
> > 'refs/{heads,tags}' in addition to 'refs/remotes'.
>
> Those who want to rename their own branches should be allowed to do
> so easily when it is convenient for them to do so, whether the
> reason for renaming their local branch is because their upstream
> renamed the branches they are interested in and have good reasons to
> use the same name, or because they made a typo when they created
> their local brnach, but I do not think renaming the local branch
> should be done automatically.

I agree that doing so automatically would not be welcome.

I like your idea in this thread about doing so with a small helper
script. I would even be OK with something in contrib that understands
'--dry-run' (to print what it would have done) and '--all' (to rename
all tracking refs at once).

Thanks,
Taylor

Re: Renaming the "master" branch without breaking existing clones

[Matt McCutchen]

On Mon, 2020-08-03 at 09:14 -0700, Junio C Hamano wrote:
> Matt McCutchen <matt@mattmccutchen.net> writes:
> 
> > 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.
> 
> I wonder if that would work well.  Your refs/remotes/origin/HEAD is
> designed to be tweaked by you to indicate which remote branch is of
> interest to you to your local Git.  Those who are interested in
> following along 'maint' can update refs/remotes/origin/HEAD to point
> at refs/remotes/origin/maint in their clone of this project, and
> they can say "git fetch origin && git log origin" to see the history
> leading to the tip of 'maint' in my repository.
> 
> At least, that is how it is designed to work.  So "compare local
> refs/remotes/origin/HEAD and what 'git ls-remote origin' sees where
> they point at with their HEAD---if they are different, ours have old
> name and theirs have new name" is not a good heuristics.

Indeed.  I guess my proposal to use the HEAD symref of the remote
repository only applies to tools that interact with a central
repository and don't have a local repository that the user is allowed
to touch (there might be one for caching purposes only) and need to
know which branch to use if the user didn't specify one.  This would
include npm, yarn, etc., as mentioned in the article I linked.

If functionality is added to git to facilitate transitions for tools
that do have a local repository that the user is allowed to touch, as
you described, that would be great.

Matt

Re: Renaming the "master" branch without breaking existing clones

[Kaartic Sivaraam]

On 03-08-2020 21:44, Junio C Hamano wrote:
> 
> If we wanted to do this properly, I'd imagine we'd need to add a
> mechanism for repositories to convey "this branch that used to exist
> got renamed to this other name", not specifically for any "special"
> branch name (like 'master').  If we plan to never allow reusing the
> old and banned name, it probably is enough to turn the old name into
> a symbolic ref that points at the new name, e.g. in my repository
> 
>     $ git update-ref refs/heads/seen refs/heads/pu
>     $ git update-ref -d refs/heads/pu
>     $ git symbolic-ref refs/heads/pu refs/heads/seen
> 
> which would create a symbolic reference 'pu' that points at 'seen'
> to say "pu used to exist but it is now seen".
> 
> But that would not work well, as we must allow reusing the old name,
> as the primary point of renaming 'pu' to 'seen' in this project was
> so that we can accept topics from contributors whose anglicized name
> has 'p' and 'u' in capital letters as pu/$topicname branches.  Having
> a symbolic ref 'pu' would defeat that plan.
> 

Of course. Though, having a symbolic ref of 'pu/seen' to 'seen' would
hopefully not defeat the plan while being a little helpful ;)

Sharing a thing that just crossed my mind while reading this.

-- 
Sivaraam

Re: Renaming the "master" branch without breaking existing clones

[Junio C Hamano]

Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:

> On 03-08-2020 21:44, Junio C Hamano wrote:
>> 
>> If we wanted to do this properly, I'd imagine we'd need to add a
>> mechanism for repositories to convey "this branch that used to exist
>> got renamed to this other name", not specifically for any "special"
>> branch name (like 'master').  If we plan to never allow reusing the
>> old and banned name, it probably is enough to turn the old name into
>> a symbolic ref that points at the new name, e.g. in my repository
>> 
>>     $ git update-ref refs/heads/seen refs/heads/pu
>>     $ git update-ref -d refs/heads/pu
>>     $ git symbolic-ref refs/heads/pu refs/heads/seen
>> 
>> which would create a symbolic reference 'pu' that points at 'seen'
>> to say "pu used to exist but it is now seen".
>> 
>> But that would not work well, as we must allow reusing the old name,
>> as the primary point of renaming 'pu' to 'seen' in this project was
>> so that we can accept topics from contributors whose anglicized name
>> has 'p' and 'u' in capital letters as pu/$topicname branches.  Having
>> a symbolic ref 'pu' would defeat that plan.
>
> Of course. Though, having a symbolic ref of 'pu/seen' to 'seen' would
> hopefully not defeat the plan while being a little helpful ;)

How would that be helpful?  After all, I do want to allow us accept
a topic about 'seen' from author 'pu', and that pu/seen branch
should be different from the "not yet ready for 'next' but at least
the maintainer acknowledges that he has seen them" integration
branch whose name is 'seen'.

Re: Renaming the "master" branch without breaking existing clones

[Jeff King]

On Mon, Aug 03, 2020 at 12:00:51PM -0400, Taylor Blau wrote:

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

I think symrefs do this already. Try this:

  git init parent
  git -C parent checkout -b main
  git -C parent commit --allow-empty -m one
  git -C parent symbolic-ref refs/heads/master refs/heads/main

  git clone parent clone
  cd clone
  GIT_TRACE_PACKET=1 git ls-remote 2>&1 >/dev/null |
  perl -lne '/git</ && /packet: (.*)/ and print $1'

Assuming you have the v2 protocol enabled, you should see:

  git< 3ba9220cd714e9350cb4becd1cb56d0cacf29d9b HEAD symref-target:refs/heads/main
  git< 3ba9220cd714e9350cb4becd1cb56d0cacf29d9b refs/heads/main
  git< 3ba9220cd714e9350cb4becd1cb56d0cacf29d9b refs/heads/master symref-target:refs/heads/main

(if you don't you'll still see them as aliases, but you won't be told
that master is a symref).

And it even works for pushing. Doing:

  git checkout -b master origin/master
  git commit --allow-empty -m two
  git push

updates both "main" and "master".

The real trick is that you can't create or update symbolic refs on the
server side using a client. So this would have to be something that
hosting providers allow (and there might be some security implications;
I'm not sure what happens if you create a loop in the symref
resolution).

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

It's not specifically marked as a transition, but a client could act on
the symref advertisement above.

-Peff

Re: Renaming the "master" branch without breaking existing clones

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> The real trick is that you can't create or update symbolic refs on the
> server side using a client. So this would have to be something that
> hosting providers allow (and there might be some security implications;
> I'm not sure what happens if you create a loop in the symref
> resolution).

Another is that the old name must be declared forever banned if we
use symbolic refs for this.  The mechanism would have fell far short
of helping transitioning from 'pu' to 'seen' for example X-<.

Re: Renaming the "master" branch without breaking existing clones

[Jeff King]

On Mon, Aug 03, 2020 at 03:40:06PM -0400, Jeff King wrote:

> On Mon, Aug 03, 2020 at 12:00:51PM -0400, Taylor Blau wrote:
> 
> > 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.
> 
> I think symrefs do this already. Try this:

Looks like Junio already mentioned symrefs. I guess I should have read
the whole thread. :)

As he noted, they don't work if you want to free up the original name.
But I think in the master/main renaming case that most people wouldn't
care that much about doing so.

> >   - 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).
> 
> It's not specifically marked as a transition, but a client could act on
> the symref advertisement above.

Something like this script could be run on the clients:

  remote=origin
  git ls-remote --symref $remote |
  grep ^ref: |
  while read junk to from; do
    if test "$from" = HEAD; then
      old=$(git symbolic-ref refs/remotes/$remote/HEAD)
      echo "Upstream switched their HEAD:"
      echo "  old: $old"
      echo "  new: $to"
      echo "Update to match?"
      read r </dev/tty
      if test "$r" = yes; then
        git symbolic-ref refs/remotes/$remote/HEAD $to
      fi
    else
      # do we even have the old branch?
      git rev-parse --verify $from >/dev/null 2>&1 || continue
      echo "Upstream is redirecting a branch:"
      echo "     branch: $from"
      echo "  points to: $to"
      echo "And you have a local $from; should we rename it?"
      read r </dev/tty
      if test "$r" = yes; then
        git branch -m ${from#refs/heads/} ${to#refs/heads/}
      fi
    fi
  done

There are probably some rough edges that could be smoothed (only looking
in refs/heads/ and using branch names instead of fully qualified refs,
handling the case that $to already exists more gracefully, better
prompting). But something like that might be useful for projects that
are transitioning.

Note that it only works with protocol v2, though, because we don't
report non-HEAD symrefs in v0.

-Peff

Re: Renaming the "master" branch without breaking existing clones

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Something like this script could be run on the clients:
>
>   remote=origin
>   git ls-remote --symref $remote |
>   grep ^ref: |
>   while read junk to from; do
>     if test "$from" = HEAD; then
>       old=$(git symbolic-ref refs/remotes/$remote/HEAD)
>       echo "Upstream switched their HEAD:"
>       echo "  old: $old"
>       echo "  new: $to"
>       echo "Update to match?"
>       read r </dev/tty
>       if test "$r" = yes; then
>         git symbolic-ref refs/remotes/$remote/HEAD $to
>       fi
>     else
>       # do we even have the old branch?
>       git rev-parse --verify $from >/dev/null 2>&1 || continue
>       echo "Upstream is redirecting a branch:"
>       echo "     branch: $from"
>       echo "  points to: $to"
>       echo "And you have a local $from; should we rename it?"
>       read r </dev/tty
>       if test "$r" = yes; then
>         git branch -m ${from#refs/heads/} ${to#refs/heads/}
>       fi
>     fi
>   done
>
> There are probably some rough edges that could be smoothed (only looking
> in refs/heads/ and using branch names instead of fully qualified refs,
> handling the case that $to already exists more gracefully, better
> prompting). But something like that might be useful for projects that
> are transitioning.
>
> Note that it only works with protocol v2, though, because we don't
> report non-HEAD symrefs in v0.

Renaming local branches themselves is probably the least interesting
part.  You could even do _without_ renaming your local branches at
all and keep working without any problem.  But you need to be able
to adjust to the renaming upstream does, so if your 'topic' branch
builds on top of 'refs/remotes/origin/master' and your upstream
renames it to 'refs/remotes/origin/stuff' you'd need to reconfigure
'topic' branch to also build on and/or integrate with 'stuff'
instead of 'master'.

Re: Renaming the "master" branch without breaking existing clones

[Jeff King]

On Mon, Aug 03, 2020 at 02:02:14PM -0700, Junio C Hamano wrote:

> > There are probably some rough edges that could be smoothed (only looking
> > in refs/heads/ and using branch names instead of fully qualified refs,
> > handling the case that $to already exists more gracefully, better
> > prompting). But something like that might be useful for projects that
> > are transitioning.
> >
> > Note that it only works with protocol v2, though, because we don't
> > report non-HEAD symrefs in v0.
> 
> Renaming local branches themselves is probably the least interesting
> part.  You could even do _without_ renaming your local branches at
> all and keep working without any problem.  But you need to be able
> to adjust to the renaming upstream does, so if your 'topic' branch
> builds on top of 'refs/remotes/origin/master' and your upstream
> renames it to 'refs/remotes/origin/stuff' you'd need to reconfigure
> 'topic' branch to also build on and/or integrate with 'stuff'
> instead of 'master'.

Yeah, good point. That would be pretty easy to add to the script I
showed by looking at:

  git config --get-regexp 'branch\..*\.merge' refs/heads/master

And I guess checking the matching branch.*.remote to match $remote. I
think we're getting to the realm where it would be easier to implement
in something besides shell. :)

But I do think a "branch renaming" helper like this might be useful for
projects undergoing this rename. I don't think it makes sense to have as
a first-class Git command, but I wouldn't be opposed to carrying
something like it in contrib/ if somebody wanted to polish it up.

-Peff

Re: Renaming the "master" branch without breaking existing clones

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> But I do think a "branch renaming" helper like this might be useful for
> projects undergoing this rename. I don't think it makes sense to have as
> a first-class Git command, but I wouldn't be opposed to carrying
> something like it in contrib/ if somebody wanted to polish it up.

Absolutely.  

I think we three are on the same page now ;-)

cf. <20200803163958.GD50799@syl.lan>
cf. <xmqqlfivwvtw.fsf@gitster.c.googlers.com>

Now one issue I am not so sure about is if the only thing that needs
adjusting is branch.*.remote + branch.*.merge.

The open-ended nature of our design means it is _possible_ to be
reasonably sure to have covered everything we do in the core part of
Git, but it is certain for us to miss third-party enhancements.

An inevitable "why not do all that when 'git branch -r -m old new'
is given?" posed by those who are not aware of the design needs to
be shot down, which is unfortunate.

Re: Renaming the "master" branch without breaking existing clones

[Matt McCutchen]

On Mon, 2020-08-03 at 15:40 -0400, Jeff King wrote:
> The real trick is that you can't create or update symbolic refs on the
> server side using a client. So this would have to be something that
> hosting providers allow (and there might be some security implications;
> I'm not sure what happens if you create a loop in the symref
> resolution).

Right, repository administrators need some kind of support for the
hosting provider (whether symrefs or something custom), otherwise the
best they can do is develop their own process to mirror the new branch
to the old branch.

GitHub mentions a plan to support a branch rename that would redirect
at least fetches of the old name, though it is short on details:

https://github.com/github/renaming#later-this-year-seamless-move-for-existing-repositories-

I've just filed feature requests for BitBucket and GitLab:

https://jira.atlassian.com/browse/BCLOUD-20349
https://gitlab.com/gitlab-org/gitlab/-/issues/233427#related-issues

Anyone want to check on other major providers?

Matt

Re: Renaming the "master" branch without breaking existing clones

[Matt McCutchen]

On Mon, 2020-08-03 at 12:00 -0400, Taylor Blau wrote:
> On Mon, Aug 03, 2020 at 08:15:58AM -0400, Matt McCutchen wrote:
> > 3. Ensuring that tools detect the default branch of a given repository
> > in an appropriate way rather than assuming "master". [...]
> 
> 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 not so sure about that.  Recently I've been the most active
contributor to Braid (https://github.com/cristibalan/braid/), and I
only learned about this today when I stumbled on news about a similar
change to the Linux kernel and immediately wondered if git was doing
the same thing.  I filed an issue (t
https://github.com/cristibalan/braid/issues/87) and will develop a fix
when I have time.

Matt

Re: Renaming the "master" branch without breaking existing clones

[Kaartic Sivaraam]

On 04-08-2020 00:17, Junio C Hamano wrote:
> Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:
> 
>>
>> Of course. Though, having a symbolic ref of 'pu/seen' to 'seen' would
>> hopefully not defeat the plan while being a little helpful ;)
> 
> How would that be helpful?  After all, I do want to allow us accept
> a topic about 'seen' from author 'pu', and that pu/seen branch
> should be different from the "not yet ready for 'next' but at least
> the maintainer acknowledges that he has seen them" integration
> branch whose name is 'seen'.
> 

I thought 'seen' was blunt for a topic name in the sense that it doesn't
convey what the topic does about 'seen'. So, having a symbolic ref of
'pu/seen' to 'seen' might be a good allusion to the fact that 'pu' has
been renamed to 'seen' just by looking at the list of remote branches.

-- 
Sivaraam