* Renaming the "master" branch without breaking existing clones @ 2020-08-03 12:15 Matt McCutchen 2020-08-03 16:00 ` Taylor Blau 2020-08-03 16:14 ` Junio C Hamano 0 siblings, 2 replies; 17+ messages in thread From: Matt McCutchen @ 2020-08-03 12:15 UTC (permalink / raw) To: git [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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 12:15 Renaming the "master" branch without breaking existing clones Matt McCutchen @ 2020-08-03 16:00 ` Taylor Blau 2020-08-03 16:19 ` Junio C Hamano ` (2 more replies) 2020-08-03 16:14 ` Junio C Hamano 1 sibling, 3 replies; 17+ messages in thread From: Taylor Blau @ 2020-08-03 16:00 UTC (permalink / raw) To: Matt McCutchen; +Cc: git 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 16:00 ` Taylor Blau @ 2020-08-03 16:19 ` Junio C Hamano 2020-08-03 16:39 ` Taylor Blau 2020-08-03 19:40 ` Jeff King 2020-08-04 0:43 ` Matt McCutchen 2 siblings, 1 reply; 17+ messages in thread From: Junio C Hamano @ 2020-08-03 16:19 UTC (permalink / raw) To: Taylor Blau; +Cc: Matt McCutchen, git 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 16:19 ` Junio C Hamano @ 2020-08-03 16:39 ` Taylor Blau 0 siblings, 0 replies; 17+ messages in thread From: Taylor Blau @ 2020-08-03 16:39 UTC (permalink / raw) To: Junio C Hamano; +Cc: Taylor Blau, Matt McCutchen, git 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 16:00 ` Taylor Blau 2020-08-03 16:19 ` Junio C Hamano @ 2020-08-03 19:40 ` Jeff King 2020-08-03 20:40 ` Junio C Hamano ` (2 more replies) 2020-08-04 0:43 ` Matt McCutchen 2 siblings, 3 replies; 17+ messages in thread From: Jeff King @ 2020-08-03 19:40 UTC (permalink / raw) To: Taylor Blau; +Cc: Matt McCutchen, git 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 19:40 ` Jeff King @ 2020-08-03 20:40 ` Junio C Hamano 2020-08-03 20:45 ` Jeff King 2020-08-04 0:37 ` Matt McCutchen 2 siblings, 0 replies; 17+ messages in thread From: Junio C Hamano @ 2020-08-03 20:40 UTC (permalink / raw) To: Jeff King; +Cc: Taylor Blau, Matt McCutchen, git 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-<. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 19:40 ` Jeff King 2020-08-03 20:40 ` Junio C Hamano @ 2020-08-03 20:45 ` Jeff King 2020-08-03 21:02 ` Junio C Hamano 2020-08-04 0:37 ` Matt McCutchen 2 siblings, 1 reply; 17+ messages in thread From: Jeff King @ 2020-08-03 20:45 UTC (permalink / raw) To: Taylor Blau; +Cc: Matt McCutchen, git 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 20:45 ` Jeff King @ 2020-08-03 21:02 ` Junio C Hamano 2020-08-03 21:11 ` Jeff King 0 siblings, 1 reply; 17+ messages in thread From: Junio C Hamano @ 2020-08-03 21:02 UTC (permalink / raw) To: Jeff King; +Cc: Taylor Blau, Matt McCutchen, git 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'. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 21:02 ` Junio C Hamano @ 2020-08-03 21:11 ` Jeff King 2020-08-03 21:38 ` Junio C Hamano 0 siblings, 1 reply; 17+ messages in thread From: Jeff King @ 2020-08-03 21:11 UTC (permalink / raw) To: Junio C Hamano; +Cc: Taylor Blau, Matt McCutchen, git 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 21:11 ` Jeff King @ 2020-08-03 21:38 ` Junio C Hamano 0 siblings, 0 replies; 17+ messages in thread From: Junio C Hamano @ 2020-08-03 21:38 UTC (permalink / raw) To: Jeff King; +Cc: Taylor Blau, Matt McCutchen, git 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 19:40 ` Jeff King 2020-08-03 20:40 ` Junio C Hamano 2020-08-03 20:45 ` Jeff King @ 2020-08-04 0:37 ` Matt McCutchen 2 siblings, 0 replies; 17+ messages in thread From: Matt McCutchen @ 2020-08-04 0:37 UTC (permalink / raw) To: Jeff King, Taylor Blau; +Cc: git 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 16:00 ` Taylor Blau 2020-08-03 16:19 ` Junio C Hamano 2020-08-03 19:40 ` Jeff King @ 2020-08-04 0:43 ` Matt McCutchen 2 siblings, 0 replies; 17+ messages in thread From: Matt McCutchen @ 2020-08-04 0:43 UTC (permalink / raw) To: Taylor Blau; +Cc: git 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 12:15 Renaming the "master" branch without breaking existing clones Matt McCutchen 2020-08-03 16:00 ` Taylor Blau @ 2020-08-03 16:14 ` Junio C Hamano 2020-08-03 17:41 ` Matt McCutchen 2020-08-03 18:20 ` Kaartic Sivaraam 1 sibling, 2 replies; 17+ messages in thread From: Junio C Hamano @ 2020-08-03 16:14 UTC (permalink / raw) To: Matt McCutchen; +Cc: git 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 16:14 ` Junio C Hamano @ 2020-08-03 17:41 ` Matt McCutchen 2020-08-03 18:20 ` Kaartic Sivaraam 1 sibling, 0 replies; 17+ messages in thread From: Matt McCutchen @ 2020-08-03 17:41 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 16:14 ` Junio C Hamano 2020-08-03 17:41 ` Matt McCutchen @ 2020-08-03 18:20 ` Kaartic Sivaraam 2020-08-03 18:47 ` Junio C Hamano 1 sibling, 1 reply; 17+ messages in thread From: Kaartic Sivaraam @ 2020-08-03 18:20 UTC (permalink / raw) To: Junio C Hamano; +Cc: Matt McCutchen, git 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 18:20 ` Kaartic Sivaraam @ 2020-08-03 18:47 ` Junio C Hamano 2020-08-04 8:50 ` Kaartic Sivaraam 0 siblings, 1 reply; 17+ messages in thread From: Junio C Hamano @ 2020-08-03 18:47 UTC (permalink / raw) To: Kaartic Sivaraam; +Cc: Matt McCutchen, git 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'. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Renaming the "master" branch without breaking existing clones 2020-08-03 18:47 ` Junio C Hamano @ 2020-08-04 8:50 ` Kaartic Sivaraam 0 siblings, 0 replies; 17+ messages in thread From: Kaartic Sivaraam @ 2020-08-04 8:50 UTC (permalink / raw) To: Junio C Hamano; +Cc: Matt McCutchen, git 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2020-08-04 8:51 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-03 12:15 Renaming the "master" branch without breaking existing clones Matt McCutchen 2020-08-03 16:00 ` Taylor Blau 2020-08-03 16:19 ` Junio C Hamano 2020-08-03 16:39 ` Taylor Blau 2020-08-03 19:40 ` Jeff King 2020-08-03 20:40 ` Junio C Hamano 2020-08-03 20:45 ` Jeff King 2020-08-03 21:02 ` Junio C Hamano 2020-08-03 21:11 ` Jeff King 2020-08-03 21:38 ` Junio C Hamano 2020-08-04 0:37 ` Matt McCutchen 2020-08-04 0:43 ` Matt McCutchen 2020-08-03 16:14 ` Junio C Hamano 2020-08-03 17:41 ` Matt McCutchen 2020-08-03 18:20 ` Kaartic Sivaraam 2020-08-03 18:47 ` Junio C Hamano 2020-08-04 8:50 ` Kaartic Sivaraam
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).