I see that qpid-broker-j was being worked on over the precise period the renames were being done, and so has unfortunately already had the master branch re-created by a push.
I've brought the main up to date with the change, but I cant delete the old master branch as its protected from being rewound. I will enquire with infra. On Wed, 31 Mar 2021 at 09:29, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > > The remaining repositories have now had their default branches renamed > from master to main, following the earlier test change. > > If you have an existing clone of a repo, you either need to re-clone > it, or manually update your local repo to ensure it reflects the > branch name change. > > For the latter these are GitHub's suggested steps: > git branch -m master main > git fetch origin > git branch -u origin/main main > > (Where 'origin' is the git remote name given to the repo, update this > as appropriate for your naming choice if different) > > Note that you will also have to do the rename in your own existing > GitHub forks if you want them to align. GitHub notifies you of the > change in its UI when you load your fork repo page, and directs you to > the relevant space in settings (essentially go to > https://github.com/<username>/<repo-name>/settings/branches and then > click the pencil to rename, type in main). > > As a final point, for those who update an existing local repo using > the steps above, you may spot you still have a 'remote ref' pointing > to origin/master (e.g if you run git branch -avv you would see an > entry like: remotes/origin/HEAD -> origin/master). This is a local > value that only gets set while cloning, based on the default branch of > the remote repo at the time. Its mostly not important but you can > update it yourself anyway. I elected to do this, by first explicitly > setting the ref to origin/main and then pruning any refs for 'origin' > (or again, whatever you named your repo remote) that dont actually > exist on the remote repo: > git remote set-head origin main > git remote prune --dry-run origin > > (Note the latter is a --dry-run, repeat the command again without that > flag if you are happy with what it said it will do, i.e it will > indicate it would prune origin/master, but will also prune any other > 'origin' refs you have for branches that no longer exist in the remote > repo) > > On Tue, 16 Mar 2021 at 17:07, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > > > > I was going to begin this tomorrow as noted below, however since I > > sent this proposal I have now been both on the receiving end of a > > GitHub-driven rename and done some of them for myself...that is, doing > > the rename with their tooling as described at > > https://github.com/github/renaming. > > > > It is a nicer process than I outlined below, with some benefits we > > wouldnt get doing it the other way. As we can actually push to the ASF > > GitHub 'mirrors' if jumping through appropriate hoops first, I decided > > to enquire with Infra whether it might actually be possible to use the > > GitHub driven approach. It isnt something they have done before, but > > said they'll take a look at it, and could perhaps use us to try it > > out. I have now raised > > https://issues.apache.org/jira/browse/INFRA-21589 for this either way, > > and I'll keep you updated with what is happening. > > > > On Thu, 11 Mar 2021 at 12:21, Robbie Gemmell <robbie.gemm...@gmail.com> > > wrote: > > > > > > Hi folks, > > > > > > I would like to propose renaming our git repository default branches > > > from "master" to "main" in keeping with general efforts to remove > > > offensive language, and also aligning with it being the default naming > > > approach on new repositories in various places for some time now. > > > > > > Having looked into doing this my understanding is that we simply > > > create the new branches ourselves, start using them, and then ask > > > infra to reconfigure the repository default branch both here and at > > > GitHub. After that is done, we can then remove the old branches at our > > > own discretion. > > > > > > Various updates could be needed as part of the process. Some CI jobs > > > and scripts etc could need to be updated, maybe some READMES etc, > > > there could be links that need updated, etc. I would take care of > > > creating the branches, requesting INFRA update the repo defaults, and > > > ensuring the CI builds and website are in order during/after the > > > change. Committers would need to update their checkouts accordingly. > > > Folks with their own CI jobs etc elsewhere may also need to make any > > > updates as appropriate. > > > > > > Barring discussion otherwise, I would look to begin the process next > > > week on Wednesday 17th. > > > > > > I would create branches in all our repositories and send a notice mail > > > that it had been done, such that committers then make the swap over > > > for pushing new work. I would then ask infra to make the repository > > > changes, and proceed with updates to CI jobs etc. Perhaps adjusting > > > the READMEs on master to make things more obvious for anyone looking > > > at the repositories while it is still the default and/or both branches > > > exist. After all is done, we can consider when/whether to remove the > > > old branches. > > > > > > Robbie --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
