threads / discuss / 53972

Renaming the "master" branch without breaking existing clones

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

## tl;dr

17 messages between Aug 3, 2020 and Aug 4, 2020.

replies: 16people: 5as markdown or json

Matt McCutchen· Aug 3, 2020, 12:15 UTC · lore

[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
Taylor Blau· Aug 3, 2020, 16:00 UTC · re: Matt McCutchen · lore

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

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/
Show 8 quoted lines
> 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.

Show 26 quoted lines
> 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.
Show 16 quoted lines
> 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.

Show 5 quoted lines
> 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

Junio C Hamano· Aug 3, 2020, 16:19 UTC · re: Taylor Blau · lore

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

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.

Taylor Blau· Aug 3, 2020, 16:39 UTC · re: Junio C Hamano · lore

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

On Mon, Aug 03, 2020 at 09:19:52AM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> 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

Jeff King· Aug 3, 2020, 19:40 UTC · re: Taylor Blau · lore

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

On Mon, Aug 03, 2020 at 12:00:51PM -0400, Taylor Blau wrote:
Show 8 quoted lines
> 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
Junio C Hamano· Aug 3, 2020, 20:40 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> writes:
Show 5 quoted lines
> 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-<.

Jeff King· Aug 3, 2020, 20:45 UTC · re: Jeff King · lore

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

On Mon, Aug 03, 2020 at 03:40:06PM -0400, Jeff King wrote:
Show 12 quoted lines
> 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.

Show 6 quoted lines
> >   - 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
Junio C Hamano· Aug 3, 2020, 21:02 UTC · re: Jeff King · lore

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

Jeff King <peff@peff.net> writes:
Show 38 quoted lines
> 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'.

Jeff King· Aug 3, 2020, 21:11 UTC · re: Junio C Hamano · lore

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

On Mon, Aug 03, 2020 at 02:02:14PM -0700, Junio C Hamano wrote:
Show 17 quoted lines
> > 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
Junio C Hamano· Aug 3, 2020, 21:38 UTC · re: Jeff King · lore

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

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.

Matt McCutchen· Aug 4, 2020, 00:37 UTC · re: Jeff King · lore

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

On Mon, 2020-08-03 at 15:40 -0400, Jeff King wrote:
Show 5 quoted lines
> 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
Matt McCutchen· Aug 4, 2020, 00:43 UTC · re: Taylor Blau · lore

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

On Mon, 2020-08-03 at 12:00 -0400, Taylor Blau wrote:
Show 6 quoted lines
> 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
Junio C Hamano· Aug 3, 2020, 16:14 UTC · re: Matt McCutchen · lore

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

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.
Matt McCutchen· Aug 3, 2020, 17:41 UTC · re: Junio C Hamano · lore

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

On Mon, 2020-08-03 at 09:14 -0700, Junio C Hamano wrote:
Show 18 quoted lines
> 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
Kaartic Sivaraam· Aug 3, 2020, 18:20 UTC · re: Junio C Hamano · lore

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

On 03-08-2020 21:44, Junio C Hamano wrote:
Show 21 quoted lines
> 
> 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
Junio C Hamano· Aug 3, 2020, 18:47 UTC · re: Kaartic Sivaraam · lore

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

Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:
Show 24 quoted lines
> 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'.

Kaartic Sivaraam· Aug 4, 2020, 08:50 UTC · re: Junio C Hamano · lore

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

On 04-08-2020 00:17, Junio C Hamano wrote:
Show 12 quoted lines
> 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

← back to recent threads