Re: Rename "master" branch to "main" for glibc 2.35 release.

[Joseph Myers <joseph@codesourcery.com>]

On Sat, 29 Jan 2022, Carlos O'Donell via Libc-alpha wrote:

> My proposal is to rename the development and release branches at the point
> that glibc 2.35 branches:
> 
> * master -> main
> 
> * release/2.35/master -> release/2.35/main
> 
> No alias would be provided for the master branch; we would immediately
> start using 'main' as the development branch.

I strongly disapprove of the approach of renaming an existing branch 
without providing an alias.  Branches aren't just consumed by active 
developers, there are many people with their own checkouts, automatically 
updating mirrors, etc., many of which may be useful to their users without 
much active maintenance and without anyone following glibc mailing lists; 
it's gratuitous to break them.

Note also that build-many-glibcs.py knows about migrating GCC checkouts 
from SVN to git, so no manual intervention whatever was needed beyond the 
use of --replace-sources when running the checkout step (which is used 
automatically in bot mode).  Naturally it should be taught to migrate from 
master to main if the master alias might ever go away (but I don't think 
such an alias should go away, certainly not for several years).

(This is not making any assertion about whether it should be possible to 
push to the master alias, just that nothing should be broken for anyone 
pulling from it.)

> I have reviewed the git hooks, and we would need to make changes to the
> following files after the transition:
> * hooks-bin/email-to-bugzilla-filtered
> * hooks-bin/post-receive
> 
> Our hooks implementation (AdaCore's hooks) is neutral on the branch name
> used. There are two instances where 'master' is removed for '' to
> shorten an email message because it's the "default", but that should not
> be a blocker for our transition.

Configuration to handle the two branch names the same in all regards 
should be done before adding a branch using the new naming conventions.

-- 
Joseph S. Myers
joseph@codesourcery.com