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

[Mike Lothian]

On Mon, 3 Aug 2020 at 18:42, Erik Faye-Lund
<erik.faye-lund at collabora.com> wrote:
>
> On Mon, 2020-08-03 at 10:30 -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?
> >
>
> I'm all for renaming it, but I'm a bit worried about doing it in a way
> where we don't break all merge-requests...
>
> As far as I know, GitLab doesn't allow changing the target-branch of a
> merge-request, so all pending merge-requests would all of a sudden
> point to the wrong branch. Unless we have a a plan for somehow making
> sure both branches are updated in lock-step in a grace-period or
> something like that...
>
> I dunno. Does anyone have any great ideas for avoiding this problem?
>
Is that one that can be fixed in GitLab itself? I imagine a lot of
projects are going to be making similar changes