You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Robbie Gemmell <ro...@gmail.com> on 2021/04/05 11:09:04 UTC

Re: [DISCUSS/NOTICE] Renaming default git repo branches to "main"

I raised https://issues.apache.org/jira/browse/INFRA-21667 to ask for
Infra to remove the qpid-proton repository 'master' branch protection
so that I could delete its accidentally-recreated master, which is now
done.

Can any committers that have not yet done so please ensure you update
your local repositories to use 'main' going forward, to help try and
avoid further occurrences of this.

As reminder, these are GitHub's recommended steps to update an
existing local repo (you can of course just do a fresh clone instead
and begin afresh):
git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a

Or alternatively, I had been doing this instead of their last step
before they added it, which achieves much the same but also prunes all
stale refs for the remote:
git remote set-head origin main
git remote prune --dry-run origin (repeating without --dry-run if
happy with the refs it says it will prune)

Robbie

On Wed, 31 Mar 2021 at 12:47, Robbie Gemmell <ro...@gmail.com> wrote:
>
> No worries, very easy thing to happen without exact coordination.
>
> On Wed, 31 Mar 2021 at 12:13, Oleksandr Rudyy <or...@gmail.com> wrote:
> >
> > Hi Robbie,
> > Thanks for branch removal.
> > My apologies, I have not checked the state of the repo before the commit.
> >
> > Kind Regards,
> > Alex
> >
> > On Wed, 31 Mar 2021 at 10:31, Robbie Gemmell <ro...@gmail.com> wrote:
> > >
> > > Infra removed the protection from master for me and I have now removed
> > > the branch again.
> > >
> > > (The same protection remains for all the other repositories for now,
> > > it will be removed if actually needed).
> > >
> > > On Wed, 31 Mar 2021 at 10:21, Robbie Gemmell <ro...@gmail.com> wrote:
> > > >
> > > > 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 <ro...@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 <ro...@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 <ro...@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-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org