I have still to update the site itself, but I did take care of
removing its repository master branch entirely with Infra's assistance
(i.e. it has no 'main' branch replacement, only asf-site is left now)
.
On Wed, 31 Mar 2021 at 14:00, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
>
> I believe I have now updated the Jenkins, GitHub Actions, and Travis
> CI job configs as needed to reflect the branch changes for the various
> repos. I updated various references in READMEs and instructions etc to
> cover the changes also.
>
> The website still needs work done to update things, I'll hopefully get
> that later today.
>
> Robbie
>
> On Wed, 31 Mar 2021 at 12:59, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> >
> > 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)
> > >
> >
> > I notice when renaming my fork branches that GitHub have updated now
> > updated their suggested steps from previously to incorporate a 4th
> > step, aimed toward achieving a similar update as the additional steps
> > I had added myself below.
> >
> > They now also suggest running this as well in addition after the above
> > steps:
> > git remote set-head origin -a
> >
> > From a search I believe this contacts the remote repo ('origin'),
> > determines its updated default branch, and updates the remotes head
> > ref to match, rather than manually setting it and pruning all
> > non-existing remote refs as I suggested below. Much the same except
> > the pruning of any other stale refs.
> >
> > > 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
