[Mesa-dev] Rename "master" branch to "main"?

[Jason Ekstrand]

On Mon, Aug 3, 2020 at 1:24 PM Eric Engestrom <eric at engestrom.ch> wrote:
>
> On Monday, 2020-08-03 10:30:29 -0500, Jason Ekstrand wrote:
> > All,
> >
> > I'm sure by now you've all seen the articles, LKML mails, and other
> > chatter around inclusive language in software.  While mesa doesn't
> > provide a whole lot of documentation (hah!), we do have a website, a
> > code-base, and a git repo and this is something that we, as a project
> > should consider.
> >
> > What I'm proposing today is simply re-naming the primary Git branch
> > from "master" to "main".  Why "main"?  Because that's what GitHub has
> > chosen "main" as their new default branch name and so it sounds to me
> > like the most likely new default.
> >
> > As far as impact on the project goes, if and when we rename the
> > primary branch, the old "master" branch will be locked (no
> > pushing/merging allowed) and all MRs will have to be re-targeted
> > against the new branch.  Fortunately, that's very easy to do.  You
> > just edit the MR and there's a little drop-down box at the top for
> > which branch it targets.  I just tested this with one of mine and it
> > seems to work ok.
> >
> > As far as other bits of language in the code-base, I'm happy to see
> > those cleaned up as people have opportunity.  I'm not aware of any
> > particularly egregious offenders.  However, changing the name of the
> > primary branch is something which will cause a brief hiccup in
> > people's development process and so warrants broader discussion.
> >
> > Thoughts?
>
> Definite +1 for me on the idea, but we do have a lot of tools and
> processes with `master` baked in. I'll try and have a look at everything
> to make sure everything supports the transition (some things will need
> to support both the old and new names), but assuming no issue there this
> would be a really good thing to do, and `main` is a good name.

I did some grepping and I noticed that as well.  Some of the tools
such as the khronos sync scripts will have to change if/when Khronos
repos make a similar transition.  I expect that to happen but don't
have a timeline.  I'll try to keep you posted on those.

For the internal ones, if you wanted to make a MR for it, we can
either land it with support for both ahead of the switch or we can
make it the first commit that goes on the new "main" branch.  In any
case, I'm not in so much of a hurry that I think we need to make the
switch ahead of getting tooling ready.

--Jason