Category: composer

In response to recent events, where American police officers have been charged with murder for the deaths of George Floyd and Rayshard Brooks, along with the protests led by the Black Lives Matter movement, many repository owners are rejecting the use of the term ‘master’ for the default branch as oppressive terminology. As Git-based repository hosting platforms are moving to make it easier for users to select alternative default branch names, Packagist is working to better support Composer package owners during this transition.

Packagist.org co-founder Jordi Boggiano explained how Composer 1.x has decent support for other default branch names. It allows users to define a branch-alias to rename the default branch to anything, while ensuring that everything still works. Composer 2.x doesn’t assign specialized meaning to master/trunk/default branch names but rather normalizes to named versions. Boggiano also highlighted a few other ways Packagist is improving the transition for people who are renaming their default branches:

In the last couple of days we further improved the experience for alternative default branch names by keeping track of the default name configured in the VCS repository. If you change your default branch to main for example, then master will not have any meaning on your repository. The default branch will receive an alias internally to 9999999-dev unless you configure a branch-alias to a different version yourself.

These changes allowed us to fix a few related issues on packagist.org. The default branch is now always shown on top in the version list. There is no more special treatment for master as a branch name, everything should work no matter what you decide to call your default branch.

While it may not be very difficult for repository owners to change the ‘master’ branch to another name, there may be more required changes to established workflows, integrations, and pipelines that reference the default branch.

The GitHubUpdater plugin is one popular plugin that may be impacted by developers renaming their default branches. Andy Fragen is currently exploring a solution that would offer developers better support for having a principal branch named something other than ‘master:’ 

It is my intention to support whatever naming scheme the developer/user of this plugin desires to use. I am currently testing a branch locally to allow for a Release Branch header to accomplish this. This would require a header in your repository with Release Branch: trunk or Release Branch: main if your move from the previous default of master.

Over the weekend, the discussion around this issue heated up on our post about renaming the ‘Master’ branch of WordPress-owned Git repositories, as well as on the original proposal. Opponents contend that these types of changes in terminology are performative and do nothing to solve real problems like the lack of diversity in tech. Proponents argue that language is powerful and even small changes like this can help new contributors feel more welcome.

GitHub is also getting pushback on its initiative to discontinue using ‘master’ for the default branch. A reddit thread has more than 2,600 comments on the issue. The consensus seems to be that GitHub’s move is merely a gesture at best, and at worst a distraction from real issues and a waste of time and resources. Many see GitHub’s move as giving “the illusion of positive change” in the place of real effort on important issues, at the expense of broken scripts and integrations.

When Nat Friedman said GitHub is already working on renaming ‘master’ to ‘main,’ some users threatened to move to GitLab over it. However, GitLab is working on a similar initiative that would let users choose their own default branch name.

“GitLab is currently fairly opinionated about the default branch name, despite this diversity of preferences – in most situations, it will create a new project with a master branch, or configured for the first new branch to be master, without any user input, and without providing any choice to the user,” GitLab engineer Nick Thomas said. His proposal aims to give users a choice when creating new projects.

Gitlab still has the problem of deciding on what to set for a default branch name when one isn’t specified. Discussion on this issue is heated as well, although more GitLab users seem to be positively disposed towards the general idea proposed in the ticket. Thomas noted that whether master is an appropriate term in this context or not is “probably best taken up at the git-project-level.”

In response to Nat Friedman’s tweet about GitHub renaming the ‘master’ branch, Petr Baudis, the person who originally chose the default names for “master” and “origin,” said he regrets using these terms.

“I picked the names ‘master (and ‘origin’) in the early Git tooling back in 2005,” Baudis said. “This probably means you shouldn’t give much weight to my name preferences. I have wished many times I would have named them ‘main’ (and ‘upstream’) instead. Glad it’s happening.”