{"thread":{"id":"53972","subject":"Renaming the \"master\" branch without breaking existing clones","startedAt":"2020-08-03T12:16:14Z","lastAt":"2020-08-04T08:51:00Z","messageCount":17,"participants":["Matt McCutchen","Taylor Blau","Junio C Hamano","Kaartic Sivaraam","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"402678","messageId":"ec960483f5008e9948271c678d51876920ab62c9.camel@mattmccutchen.net","threadId":"53972","inReplyTo":null,"subject":"Renaming the \"master\" branch without breaking existing clones","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2020-08-03T12:15:58Z","receivedAt":"2020-08-03T12:16:14Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"[Apologies if there is an existing thread about this; I searched hard\nand wasn't able to find one.]\n\nI've just become aware of the discussion that the name of the \"master\"\nbranch should be changed. I'm not taking a position on this now, but\nit seems enough people want to make the change that we should resolve\nthe technical problems, of which I see several:\n\n1. Allowing tools to be configured to change the default name for new\nrepositories. Work on this appears to be well underway with no\nfundamental obstacles.\n\n2. Renaming the branch in existing repositories. I've seen a number of\nguides for how to do it in the central repository, and they all seem to\nexpect users with existing clones to manually reconfigure them all at\nonce. To me, that amount of disruption would be unacceptable for\ncentral repositories I'm in charge of (admittedly few with few users,\nso I imagine some will argue I should leave it to the bigger players to\ncomplain about this), whether or not one believes that the social\njustice benefit of changing the branch name in personal clones merits\nthe work at all. I found only one guide that addresses this problem:\n\nhttps://github.com/chancancode/branch-rename#gradual-migration\n\nIt includes a procedure to mirror the \"master\" branch from the new\ndefault branch so that readers of the central repository don't need to\nreconfigure anything. Writers need to be reconfigured. That seems\nreasonable to me.\n\nUnfortunately, the mirroring method seems to be specific to the\nrepository hosting service being used. If services supported standard\ngit hooks, that would probably work, but I can understand if the\nservices don't because it's unwieldy to execute shell scripts without\nintroducing security risks.\n\nThis guide seems well thought out to me on a first read, but I suspect\nthere may be aspects that could benefit from a lot more scrutiny from\nexperts, and I want to encourage them to provide it.\n\n3. Ensuring that tools detect the default branch of a given repository\nin an appropriate way rather than assuming \"master\". Where applicable,\nthe remote HEAD symref is probably the best thing to use. See for\nexample:\n\nhttps://github.com/chancancode/branch-rename#packages-considerations\n\nThis category would also include git's feature of leaving the target\nbranch name out of the merge message, for example. I believe the\nnecessary work on git itself is underway; other tools may lag.\n\nFor read-only tools, this mainly matters for central repositories that\neventually delete their \"master\" branch, which may not be all of them,\nbut again, it sounds like there will be enough such repositories that\nwe should consider the problem. I don't see any fundamental obstacle,\nbut this may benefit from more scrutiny as well.\n\nI'm aware that asking others to do work is often poorly received. This\nmessage is just to get people's attention so they can do the work if\nthey wish.\n\nThanks for reading.\n\nMatt\n\n"},{"id":"402691","messageId":"20200803160051.GA50799@syl.lan","threadId":"53972","inReplyTo":"ec960483f5008e9948271c678d51876920ab62c9.camel@mattmccutchen.net","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2020-08-03T16:00:51Z","receivedAt":"2020-08-03T16:00:58Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Mon, Aug 03, 2020 at 08:15:58AM -0400, Matt McCutchen wrote:\n> [Apologies if there is an existing thread about this; I searched hard\n> and wasn't able to find one.]\n\nPerhaps this isn't exactly what you're going for, but I raised a similar\npoint a couple of months ago:\n\n https://lore.kernel.org/git/20200611010720.GA21728@syl.local/\n\n> I've just become aware of the discussion that the name of the \"master\"\n> branch should be changed. I'm not taking a position on this now, but\n> it seems enough people want to make the change that we should resolve\n> the technical problems, of which I see several:\n>\n> 1. Allowing tools to be configured to change the default name for new\n> repositories. Work on this appears to be well underway with no\n> fundamental obstacles.\n\nYes, this was released with 2.28. Users can set 'init.defaultBranch' and\nhave 'git init' respect it when creating the first branch in a new\nrepository.\n\n> 2. Renaming the branch in existing repositories. I've seen a number of\n> guides for how to do it in the central repository, and they all seem to\n> expect users with existing clones to manually reconfigure them all at\n> once. To me, that amount of disruption would be unacceptable for\n> central repositories I'm in charge of (admittedly few with few users,\n> so I imagine some will argue I should leave it to the bigger players to\n> complain about this), whether or not one believes that the social\n> justice benefit of changing the branch name in personal clones merits\n> the work at all. I found only one guide that addresses this problem:\n>\n> https://github.com/chancancode/branch-rename#gradual-migration\n>\n> It includes a procedure to mirror the \"master\" branch from the new\n> default branch so that readers of the central repository don't need to\n> reconfigure anything. Writers need to be reconfigured. That seems\n> reasonable to me.\n>\n> Unfortunately, the mirroring method seems to be specific to the\n> repository hosting service being used. If services supported standard\n> git hooks, that would probably work, but I can understand if the\n> services don't because it's unwieldy to execute shell scripts without\n> introducing security risks.\n>\n> This guide seems well thought out to me on a first read, but I suspect\n> there may be aspects that could benefit from a lot more scrutiny from\n> experts, and I want to encourage them to provide it.\n\nThis is more-or-less what I was proposing in the message that I linked\nabove. Maybe a more solidified proposal might look something as follows:\n\n - We could introduce a mechanism to mark certain refs as aliases to\n other refs. For example, a remote might publish its\n 'refs/heads/master' as an alias to 'refs/heads/main', so that any\n reads or writes to the former get applied to the latter\n transparently.\n\n - A ref alias can be annotated to say \"I am a transition ref alias\",\n i.e., that clients should be taught to rename their copy of 'master'\n to 'main' (and update remote-tracking refs accordingly).\n\n - Clients can enable/disable automatic branch renaming.\n\nI am a little uncomfortable with the idea that a 'git pull' would modify\n'refs/{heads,tags}' in addition to 'refs/remotes'. We expect that 'git\npull' will touch remote refs, and we sometimes expect it to update\nnon-remote refs when they are remote-tracking.\n\nSo, I think that you'd only want to let ref aliases automatically\nrename remote tracking references, and only if the user opted in to\nautomatic renaming.\n\nI'm not sure, though. I haven't thought about it too much.\n\n> 3. Ensuring that tools detect the default branch of a given repository\n> in an appropriate way rather than assuming \"master\". Where applicable,\n> the remote HEAD symref is probably the best thing to use. See for\n> example:\n>\n> https://github.com/chancancode/branch-rename#packages-considerations\n>\n> This category would also include git's feature of leaving the target\n> branch name out of the merge message, for example. I believe the\n> necessary work on git itself is underway; other tools may lag.\n>\n> For read-only tools, this mainly matters for central repositories that\n> eventually delete their \"master\" branch, which may not be all of them,\n> but again, it sounds like there will be enough such repositories that\n> we should consider the problem. I don't see any fundamental obstacle,\n> but this may benefit from more scrutiny as well.\n\nI'm less qualified to talk about what's going on here, but my\nunderstanding is that providers and tool-makers are quite aware of this.\n\n> I'm aware that asking others to do work is often poorly received. This\n> message is just to get people's attention so they can do the work if\n> they wish.\n>\n> Thanks for reading.\n\nThanks for your concern.\n\n> Matt\n\nThanks,\nTaylor\n"},{"id":"402693","messageId":"xmqqlfivwvtw.fsf@gitster.c.googlers.com","threadId":"53972","inReplyTo":"ec960483f5008e9948271c678d51876920ab62c9.camel@mattmccutchen.net","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-03T16:14:19Z","receivedAt":"2020-08-03T16:14:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matt McCutchen writes:\n\n> 3. Ensuring that tools detect the default branch of a given repository\n> in an appropriate way rather than assuming \"master\". Where applicable,\n> the remote HEAD symref is probably the best thing to use.\n\nI wonder if that would work well. Your refs/remotes/origin/HEAD is\ndesigned to be tweaked by you to indicate which remote branch is of\ninterest to you to your local Git. Those who are interested in\nfollowing along 'maint' can update refs/remotes/origin/HEAD to point\nat refs/remotes/origin/maint in their clone of this project, and\nthey can say \"git fetch origin && git log origin\" to see the history\nleading to the tip of 'maint' in my repository.\n\nAt least, that is how it is designed to work. So \"compare local\nrefs/remotes/origin/HEAD and what 'git ls-remote origin' sees where\nthey point at with their HEAD---if they are different, ours have old\nname and theirs have new name\" is not a good heuristics.\n\nIf we wanted to do this properly, I'd imagine we'd need to add a\nmechanism for repositories to convey \"this branch that used to exist\ngot renamed to this other name\", not specifically for any \"special\"\nbranch name (like 'master'). If we plan to never allow reusing the\nold and banned name, it probably is enough to turn the old name into\na symbolic ref that points at the new name, e.g. in my repository\n\n $ git update-ref refs/heads/seen refs/heads/pu\n $ git update-ref -d refs/heads/pu\n $ git symbolic-ref refs/heads/pu refs/heads/seen\n\nwhich would create a symbolic reference 'pu' that points at 'seen'\nto say \"pu used to exist but it is now seen\".\n\nBut that would not work well, as we must allow reusing the old name,\nas the primary point of renaming 'pu' to 'seen' in this project was\nso that we can accept topics from contributors whose anglicized name\nhas 'p' and 'u' in capital letters as pu/$topicname branches. Having\na symbolic ref 'pu' would defeat that plan.\n\nSo perhaps we'd need to emply the usual trick to have a blob on\n\"meta\" ref, say \"refs/meta/ref-rename\" might contain multiple tuples\nthat tells the receiving end about each moved ref:\n\n - the name of the 'old' ref (e.g. 'refs/heads/pu')\n - the name of the 'new' ref (e.g. 'refs/heads/seen')\n - (optional) when the 'move' happened\n\nAs it does not make much sense to perform the local side migration\nsilently and behind the user's back while the user is actively\nworking in the repository, it is likely that the migration\ninstruction would be written as a \"perform this when it is\nconvenient for you\" one-time event. It may start by fetching the\n\"meta/ref-rename\" blob and perform \"what to do when remote ref X is\nmoved to remote ref Y\" procedure.\n\nThat procedure should also be executable offline, without the remote\nend publishing the \"meta/ref-rename\" data. If you know your upstream\nhas changed 'pu' to 'seen', you should be able to do\n\n $ git ref-migration-helper refs/remotes/origin/pu refs/remotes/origin/seen\n\nso that many things related to these names are changed (and that is\nthe most complex part---compared to that, conveying what rename the\nremote end did to the local Git is much simpler), including\n\n - renaming the remote-tracking branches (obvious)\n\n - reconfiguring local branches that have their upstream branch\n set to the 'old' remote-tracking branch to make their upstream\n branch to the 'new' remote-tracking branch.\n\nThere may be others.\n\n"},{"id":"402694","messageId":"xmqqh7tjwvkn.fsf@gitster.c.googlers.com","threadId":"53972","inReplyTo":"20200803160051.GA50799@syl.lan","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-03T16:19:52Z","receivedAt":"2020-08-03T16:19:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n> I am a little uncomfortable with the idea that a 'git pull' would modify\n> 'refs/{heads,tags}' in addition to 'refs/remotes'.\n\nThose who want to rename their own branches should be allowed to do\nso easily when it is convenient for them to do so, whether the\nreason for renaming their local branch is because their upstream\nrenamed the branches they are interested in and have good reasons to\nuse the same name, or because they made a typo when they created\ntheir local brnach, but I do not think renaming the local branch\nshould be done automatically.\n"},{"id":"402698","messageId":"20200803163958.GD50799@syl.lan","threadId":"53972","inReplyTo":"xmqqh7tjwvkn.fsf@gitster.c.googlers.com","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2020-08-03T16:39:58Z","receivedAt":"2020-08-03T16:40:02Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Mon, Aug 03, 2020 at 09:19:52AM -0700, Junio C Hamano wrote:\n> Taylor Blau writes:\n>\n> > I am a little uncomfortable with the idea that a 'git pull' would modify\n> > 'refs/{heads,tags}' in addition to 'refs/remotes'.\n>\n> Those who want to rename their own branches should be allowed to do\n> so easily when it is convenient for them to do so, whether the\n> reason for renaming their local branch is because their upstream\n> renamed the branches they are interested in and have good reasons to\n> use the same name, or because they made a typo when they created\n> their local brnach, but I do not think renaming the local branch\n> should be done automatically.\n\nI agree that doing so automatically would not be welcome.\n\nI like your idea in this thread about doing so with a small helper\nscript. I would even be OK with something in contrib that understands\n'--dry-run' (to print what it would have done) and '--all' (to rename\nall tracking refs at once).\n\nThanks,\nTaylor\n"},{"id":"402705","messageId":"ce0283e1cb38dc84eb850e3cfc7b1a6225a60b42.camel@mattmccutchen.net","threadId":"53972","inReplyTo":"xmqqlfivwvtw.fsf@gitster.c.googlers.com","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2020-08-03T17:41:40Z","receivedAt":"2020-08-03T17:41:49Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"On Mon, 2020-08-03 at 09:14 -0700, Junio C Hamano wrote:\n> Matt McCutchen writes:\n> \n> > 3. Ensuring that tools detect the default branch of a given repository\n> > in an appropriate way rather than assuming \"master\". Where applicable,\n> > the remote HEAD symref is probably the best thing to use.\n> \n> I wonder if that would work well. Your refs/remotes/origin/HEAD is\n> designed to be tweaked by you to indicate which remote branch is of\n> interest to you to your local Git. Those who are interested in\n> following along 'maint' can update refs/remotes/origin/HEAD to point\n> at refs/remotes/origin/maint in their clone of this project, and\n> they can say \"git fetch origin && git log origin\" to see the history\n> leading to the tip of 'maint' in my repository.\n> \n> At least, that is how it is designed to work. So \"compare local\n> refs/remotes/origin/HEAD and what 'git ls-remote origin' sees where\n> they point at with their HEAD---if they are different, ours have old\n> name and theirs have new name\" is not a good heuristics.\n\nIndeed. I guess my proposal to use the HEAD symref of the remote\nrepository only applies to tools that interact with a central\nrepository and don't have a local repository that the user is allowed\nto touch (there might be one for caching purposes only) and need to\nknow which branch to use if the user didn't specify one. This would\ninclude npm, yarn, etc., as mentioned in the article I linked.\n\nIf functionality is added to git to facilitate transitions for tools\nthat do have a local repository that the user is allowed to touch, as\nyou described, that would be great.\n\nMatt\n\n"},{"id":"402717","messageId":"c014fe87-9663-3ff4-9527-bf60ff30d0d9@gmail.com","threadId":"53972","inReplyTo":"xmqqlfivwvtw.fsf@gitster.c.googlers.com","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2020-08-03T18:20:29Z","receivedAt":"2020-08-03T18:20:34Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On 03-08-2020 21:44, Junio C Hamano wrote:\n> \n> If we wanted to do this properly, I'd imagine we'd need to add a\n> mechanism for repositories to convey \"this branch that used to exist\n> got renamed to this other name\", not specifically for any \"special\"\n> branch name (like 'master'). If we plan to never allow reusing the\n> old and banned name, it probably is enough to turn the old name into\n> a symbolic ref that points at the new name, e.g. in my repository\n> \n> $ git update-ref refs/heads/seen refs/heads/pu\n> $ git update-ref -d refs/heads/pu\n> $ git symbolic-ref refs/heads/pu refs/heads/seen\n> \n> which would create a symbolic reference 'pu' that points at 'seen'\n> to say \"pu used to exist but it is now seen\".\n> \n> But that would not work well, as we must allow reusing the old name,\n> as the primary point of renaming 'pu' to 'seen' in this project was\n> so that we can accept topics from contributors whose anglicized name\n> has 'p' and 'u' in capital letters as pu/$topicname branches. Having\n> a symbolic ref 'pu' would defeat that plan.\n> \n\nOf course. Though, having a symbolic ref of 'pu/seen' to 'seen' would\nhopefully not defeat the plan while being a little helpful ;)\n\nSharing a thing that just crossed my mind while reading this.\n\n-- \nSivaraam\n"},{"id":"402724","messageId":"xmqqtuxjva6w.fsf@gitster.c.googlers.com","threadId":"53972","inReplyTo":"c014fe87-9663-3ff4-9527-bf60ff30d0d9@gmail.com","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-03T18:47:03Z","receivedAt":"2020-08-03T18:47:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam writes:\n\n> On 03-08-2020 21:44, Junio C Hamano wrote:\n>> \n>> If we wanted to do this properly, I'd imagine we'd need to add a\n>> mechanism for repositories to convey \"this branch that used to exist\n>> got renamed to this other name\", not specifically for any \"special\"\n>> branch name (like 'master'). If we plan to never allow reusing the\n>> old and banned name, it probably is enough to turn the old name into\n>> a symbolic ref that points at the new name, e.g. in my repository\n>> \n>> $ git update-ref refs/heads/seen refs/heads/pu\n>> $ git update-ref -d refs/heads/pu\n>> $ git symbolic-ref refs/heads/pu refs/heads/seen\n>> \n>> which would create a symbolic reference 'pu' that points at 'seen'\n>> to say \"pu used to exist but it is now seen\".\n>> \n>> But that would not work well, as we must allow reusing the old name,\n>> as the primary point of renaming 'pu' to 'seen' in this project was\n>> so that we can accept topics from contributors whose anglicized name\n>> has 'p' and 'u' in capital letters as pu/$topicname branches. Having\n>> a symbolic ref 'pu' would defeat that plan.\n>\n> Of course. Though, having a symbolic ref of 'pu/seen' to 'seen' would\n> hopefully not defeat the plan while being a little helpful ;)\n\nHow would that be helpful? After all, I do want to allow us accept\na topic about 'seen' from author 'pu', and that pu/seen branch\nshould be different from the \"not yet ready for 'next' but at least\nthe maintainer acknowledges that he has seen them\" integration\nbranch whose name is 'seen'.\n"},{"id":"402744","messageId":"20200803194006.GA2715275@coredump.intra.peff.net","threadId":"53972","inReplyTo":"20200803160051.GA50799@syl.lan","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-08-03T19:40:06Z","receivedAt":"2020-08-03T19:40:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 03, 2020 at 12:00:51PM -0400, Taylor Blau wrote:\n\n> This is more-or-less what I was proposing in the message that I linked\n> above. Maybe a more solidified proposal might look something as follows:\n> \n> - We could introduce a mechanism to mark certain refs as aliases to\n> other refs. For example, a remote might publish its\n> 'refs/heads/master' as an alias to 'refs/heads/main', so that any\n> reads or writes to the former get applied to the latter\n> transparently.\n\nI think symrefs do this already. Try this:\n\n git init parent\n git -C parent checkout -b main\n git -C parent commit --allow-empty -m one\n git -C parent symbolic-ref refs/heads/master refs/heads/main\n\n git clone parent clone\n cd clone\n GIT_TRACE_PACKET=1 git ls-remote 2>&1 >/dev/null |\n perl -lne '/git - A ref alias can be annotated to say \"I am a transition ref alias\",\n> i.e., that clients should be taught to rename their copy of 'master'\n> to 'main' (and update remote-tracking refs accordingly).\n\nIt's not specifically marked as a transition, but a client could act on\nthe symref advertisement above.\n\n-Peff\n"},{"id":"402751","messageId":"xmqq8sevv4x5.fsf@gitster.c.googlers.com","threadId":"53972","inReplyTo":"20200803194006.GA2715275@coredump.intra.peff.net","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-03T20:40:54Z","receivedAt":"2020-08-03T20:40:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> The real trick is that you can't create or update symbolic refs on the\n> server side using a client. So this would have to be something that\n> hosting providers allow (and there might be some security implications;\n> I'm not sure what happens if you create a loop in the symref\n> resolution).\n\nAnother is that the old name must be declared forever banned if we\nuse symbolic refs for this. The mechanism would have fell far short\nof helping transitioning from 'pu' to 'seen' for example X-<.\n\n"},{"id":"402752","messageId":"20200803204503.GB2715275@coredump.intra.peff.net","threadId":"53972","inReplyTo":"20200803194006.GA2715275@coredump.intra.peff.net","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-08-03T20:45:03Z","receivedAt":"2020-08-03T20:45:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 03, 2020 at 03:40:06PM -0400, Jeff King wrote:\n\n> On Mon, Aug 03, 2020 at 12:00:51PM -0400, Taylor Blau wrote:\n> \n> > This is more-or-less what I was proposing in the message that I linked\n> > above. Maybe a more solidified proposal might look something as follows:\n> > \n> > - We could introduce a mechanism to mark certain refs as aliases to\n> > other refs. For example, a remote might publish its\n> > 'refs/heads/master' as an alias to 'refs/heads/main', so that any\n> > reads or writes to the former get applied to the latter\n> > transparently.\n> \n> I think symrefs do this already. Try this:\n\nLooks like Junio already mentioned symrefs. I guess I should have read\nthe whole thread. :)\n\nAs he noted, they don't work if you want to free up the original name.\nBut I think in the master/main renaming case that most people wouldn't\ncare that much about doing so.\n\n> > - A ref alias can be annotated to say \"I am a transition ref alias\",\n> > i.e., that clients should be taught to rename their copy of 'master'\n> > to 'main' (and update remote-tracking refs accordingly).\n> \n> It's not specifically marked as a transition, but a client could act on\n> the symref advertisement above.\n\nSomething like this script could be run on the clients:\n\n remote=origin\n git ls-remote --symref $remote |\n grep ^ref: |\n while read junk to from; do\n if test \"$from\" = HEAD; then\n old=$(git symbolic-ref refs/remotes/$remote/HEAD)\n echo \"Upstream switched their HEAD:\"\n echo \" old: $old\"\n echo \" new: $to\"\n echo \"Update to match?\"\n read r /dev/null 2>&1 || continue\n echo \"Upstream is redirecting a branch:\"\n echo \" branch: $from\"\n echo \" points to: $to\"\n echo \"And you have a local $from; should we rename it?\"\n read r writes:\n\n> Something like this script could be run on the clients:\n>\n> remote=origin\n> git ls-remote --symref $remote |\n> grep ^ref: |\n> while read junk to from; do\n> if test \"$from\" = HEAD; then\n> old=$(git symbolic-ref refs/remotes/$remote/HEAD)\n> echo \"Upstream switched their HEAD:\"\n> echo \" old: $old\"\n> echo \" new: $to\"\n> echo \"Update to match?\"\n> read r if test \"$r\" = yes; then\n> git symbolic-ref refs/remotes/$remote/HEAD $to\n> fi\n> else\n> # do we even have the old branch?\n> git rev-parse --verify $from >/dev/null 2>&1 || continue\n> echo \"Upstream is redirecting a branch:\"\n> echo \" branch: $from\"\n> echo \" points to: $to\"\n> echo \"And you have a local $from; should we rename it?\"\n> read r if test \"$r\" = yes; then\n> git branch -m ${from#refs/heads/} ${to#refs/heads/}\n> fi\n> fi\n> done\n>\n> There are probably some rough edges that could be smoothed (only looking\n> in refs/heads/ and using branch names instead of fully qualified refs,\n> handling the case that $to already exists more gracefully, better\n> prompting). But something like that might be useful for projects that\n> are transitioning.\n>\n> Note that it only works with protocol v2, though, because we don't\n> report non-HEAD symrefs in v0.\n\nRenaming local branches themselves is probably the least interesting\npart. You could even do _without_ renaming your local branches at\nall and keep working without any problem. But you need to be able\nto adjust to the renaming upstream does, so if your 'topic' branch\nbuilds on top of 'refs/remotes/origin/master' and your upstream\nrenames it to 'refs/remotes/origin/stuff' you'd need to reconfigure\n'topic' branch to also build on and/or integrate with 'stuff'\ninstead of 'master'.\n\n"},{"id":"402757","messageId":"20200803211112.GA2720049@coredump.intra.peff.net","threadId":"53972","inReplyTo":"xmqq1rknv3xl.fsf@gitster.c.googlers.com","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-08-03T21:11:12Z","receivedAt":"2020-08-03T21:11:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 03, 2020 at 02:02:14PM -0700, Junio C Hamano wrote:\n\n> > There are probably some rough edges that could be smoothed (only looking\n> > in refs/heads/ and using branch names instead of fully qualified refs,\n> > handling the case that $to already exists more gracefully, better\n> > prompting). But something like that might be useful for projects that\n> > are transitioning.\n> >\n> > Note that it only works with protocol v2, though, because we don't\n> > report non-HEAD symrefs in v0.\n> \n> Renaming local branches themselves is probably the least interesting\n> part. You could even do _without_ renaming your local branches at\n> all and keep working without any problem. But you need to be able\n> to adjust to the renaming upstream does, so if your 'topic' branch\n> builds on top of 'refs/remotes/origin/master' and your upstream\n> renames it to 'refs/remotes/origin/stuff' you'd need to reconfigure\n> 'topic' branch to also build on and/or integrate with 'stuff'\n> instead of 'master'.\n\nYeah, good point. That would be pretty easy to add to the script I\nshowed by looking at:\n\n git config --get-regexp 'branch\\..*\\.merge' refs/heads/master\n\nAnd I guess checking the matching branch.*.remote to match $remote. I\nthink we're getting to the realm where it would be easier to implement\nin something besides shell. :)\n\nBut I do think a \"branch renaming\" helper like this might be useful for\nprojects undergoing this rename. I don't think it makes sense to have as\na first-class Git command, but I wouldn't be opposed to carrying\nsomething like it in contrib/ if somebody wanted to polish it up.\n\n-Peff\n"},{"id":"402760","messageId":"xmqqwo2ftnoz.fsf@gitster.c.googlers.com","threadId":"53972","inReplyTo":"20200803211112.GA2720049@coredump.intra.peff.net","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-08-03T21:38:20Z","receivedAt":"2020-08-03T21:38:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> But I do think a \"branch renaming\" helper like this might be useful for\n> projects undergoing this rename. I don't think it makes sense to have as\n> a first-class Git command, but I wouldn't be opposed to carrying\n> something like it in contrib/ if somebody wanted to polish it up.\n\nAbsolutely. \n\nI think we three are on the same page now ;-)\n\ncf. <20200803163958.GD50799@syl.lan>\ncf. \n\nNow one issue I am not so sure about is if the only thing that needs\nadjusting is branch.*.remote + branch.*.merge.\n\nThe open-ended nature of our design means it is _possible_ to be\nreasonably sure to have covered everything we do in the core part of\nGit, but it is certain for us to miss third-party enhancements.\n\nAn inevitable \"why not do all that when 'git branch -r -m old new'\nis given?\" posed by those who are not aware of the design needs to\nbe shot down, which is unfortunate.\n\n\n\n"},{"id":"402779","messageId":"baea11c61973ff4be5ad33499d80f8629e2e1261.camel@mattmccutchen.net","threadId":"53972","inReplyTo":"20200803194006.GA2715275@coredump.intra.peff.net","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2020-08-04T00:37:36Z","receivedAt":"2020-08-04T00:37:44Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"On Mon, 2020-08-03 at 15:40 -0400, Jeff King wrote:\n> The real trick is that you can't create or update symbolic refs on the\n> server side using a client. So this would have to be something that\n> hosting providers allow (and there might be some security implications;\n> I'm not sure what happens if you create a loop in the symref\n> resolution).\n\nRight, repository administrators need some kind of support for the\nhosting provider (whether symrefs or something custom), otherwise the\nbest they can do is develop their own process to mirror the new branch\nto the old branch.\n\nGitHub mentions a plan to support a branch rename that would redirect\nat least fetches of the old name, though it is short on details:\n\nhttps://github.com/github/renaming#later-this-year-seamless-move-for-existing-repositories-\n\nI've just filed feature requests for BitBucket and GitLab:\n\nhttps://jira.atlassian.com/browse/BCLOUD-20349\nhttps://gitlab.com/gitlab-org/gitlab/-/issues/233427#related-issues\n\nAnyone want to check on other major providers?\n\nMatt\n\n"},{"id":"402780","messageId":"0f1c557657b46ec4124ca37816a3e0aa4bd83501.camel@mattmccutchen.net","threadId":"53972","inReplyTo":"20200803160051.GA50799@syl.lan","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Matt McCutchen","fromEmail":"matt@mattmccutchen.net","sentAt":"2020-08-04T00:43:34Z","receivedAt":"2020-08-04T00:43:41Z","isPatch":false,"sender":{"key":"matt@mattmccutchen.net","avatar":"https://avatars.githubusercontent.com/u/8885753?v=4"},"body":"On Mon, 2020-08-03 at 12:00 -0400, Taylor Blau wrote:\n> On Mon, Aug 03, 2020 at 08:15:58AM -0400, Matt McCutchen wrote:\n> > 3. Ensuring that tools detect the default branch of a given repository\n> > in an appropriate way rather than assuming \"master\". [...]\n> \n> I'm less qualified to talk about what's going on here, but my\n> understanding is that providers and tool-makers are quite aware of this.\n\nI'm not so sure about that. Recently I've been the most active\ncontributor to Braid (https://github.com/cristibalan/braid/), and I\nonly learned about this today when I stumbled on news about a similar\nchange to the Linux kernel and immediately wondered if git was doing\nthe same thing. I filed an issue (t\nhttps://github.com/cristibalan/braid/issues/87) and will develop a fix\nwhen I have time.\n\nMatt\n\n"},{"id":"402804","messageId":"90305e1e-c161-42f3-ab3b-92fc423d17c6@gmail.com","threadId":"53972","inReplyTo":"xmqqtuxjva6w.fsf@gitster.c.googlers.com","subject":"Re: Renaming the \"master\" branch without breaking existing clones","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2020-08-04T08:50:54Z","receivedAt":"2020-08-04T08:51:00Z","isPatch":false,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On 04-08-2020 00:17, Junio C Hamano wrote:\n> Kaartic Sivaraam writes:\n> \n>>\n>> Of course. Though, having a symbolic ref of 'pu/seen' to 'seen' would\n>> hopefully not defeat the plan while being a little helpful ;)\n> \n> How would that be helpful? After all, I do want to allow us accept\n> a topic about 'seen' from author 'pu', and that pu/seen branch\n> should be different from the \"not yet ready for 'next' but at least\n> the maintainer acknowledges that he has seen them\" integration\n> branch whose name is 'seen'.\n> \n\nI thought 'seen' was blunt for a topic name in the sense that it doesn't\nconvey what the topic does about 'seen'. So, having a symbolic ref of\n'pu/seen' to 'seen' might be a good allusion to the fact that 'pu' has\nbeen renamed to 'seen' just by looking at the list of remote branches.\n\n-- \nSivaraam\n"}]}