The team behind version control system Git has pushed out version 2.28 of its project, adding the promised mechanism for easily setting a default name for new repos, amongst other things.
The latter is a reaction to the industry slowly moving away from questionable designations like master and slave, blacklist and whitelist. In a blog entry co-written with the Software Freedom Conservancy, the Git project acknowledged that their initial default branch name master “is offensive to some people” and encouraged projects to “switch to branch names that are meaningful and inclusive”.
The new configuration option init.defaultBranch is meant to help with that. It allows admins to set a new standard name used for all new repositories by typing something like git config –global init.defaultBranch main, while helping the Git project to “eventually wean ourselves off” the hard coded identifier, as maintainer Junio C Hamano put it.
Even though it was always comparatively easy to change a branch’s name, the new option surely serves as a welcome assistance for teams looking to set new defaults. It also can be seen as a sign for projects that in the last couple of months have been looking to Git for guidance on naming.
Despite the shorter than usual development cycle, that’s not all the new version has to offer. Devs already heavily using the sparse checkout feature introduced earlier this year, for example, get a bit more support in Git 2.28, with git-prompt now including a sparsity state and wt-status displaying a sparse checkout status. Meanwhile git gui users will surely be interested to read that the tool finally allows to open work trees from the start-up dialog.
Other than that, command line completion has learned to complete the options for the switch command, and should now work correctly with set -u and stash -p. Also, commands of the diff family are said to take the diff.relative configuration variable into account in v2.28.
Looking under the hood, code clean-up works on git fetch and clean have progressed which should improve performance, while the rewrite of git submodule now has the set-branch subcommand under its belt. When looking for information on which paths have been touched by a certain commit, git log -L… has started considering the commit-graph system – an aid that git merge-base –is-ancestor now takes advantage of as well.
A complete list of changes can be found in the announcement mail on the Git mailing list.