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

[Eric Engestrom]

On Monday, 2020-08-03 13:42:28 -0500, Jason Ekstrand wrote:
> On Mon, Aug 3, 2020 at 1:38 PM Eric Engestrom <eric at engestrom.ch> wrote:
> >
> > On Monday, 2020-08-03 13:31:19 -0500, Jason Ekstrand wrote:
> > > 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.
> >
> > The external things like Khronos should be easy enough to handle, I was
> > more concerned about internal things like the stable branches.
> >
> > >
> > > 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.
> >
> > No hurry either... except a branchpoint like the one happening in 2
> > days is the perfect time to minimize issues, as we could have eg.
> > `master` for VERSION<20.2 and `main` for VERSION>=20.2 which would
> > make it trivial for tools to know which branch name to use based on
> > the VERSION file.
> 
> Pardon me for being a bit daft but what's the issue there?  "main"
> will contain all of the commits in "master" with exactly the same
> SHAs.  The tools shouldn't have to make a distinction, I wouldn't
> think.  What am I missing?

Heh, I'm the daft one :]

You're right, there's absolutely no issue here!