> It allows changing the name of the branch that is created by git init > using a configuration variable. Nothing else. And I'm all for it. Having an QoL feature to do something that you could already do is always welcome. We only care about what the default is, for reasons already mentioned. Having an extra flag requires user input, the user knows about that their main branch is something other than the default master. Most user won't be using this flag, and they will stick to the default. And when they start using a service, that service also assumes that the default name is the same. These services are probably already configurable to change on which branch they operate because git also allows to change it already. But many people will just stick to the default. When these services change this assumption, everyone else who relied on it has to explicitly set the service back, or rename. One example is shields.io https://github.com/badges/shields/issues/5215 Changing the default is frowned upon because it solves nothing and just causes problems, as other services has to change their assumptions. (And this doesn't make them bad software as others said previously. If you have to interact with a repository remotely without being able to ask questions first, you have to make assumptions to provide optional parameters, and these optional parameters will only be set if you know that you don't use the expected default, and many people already did, breaking their setup when the service provider changes this assumption) Giving the ability to change it more easily than before, is a welcome change. What git can't control anyway is what GitHub, GitLab and the others will do, and they already can without changing anything. If GitHub decides to break these services and cause fragmentation, that's a thing not to be discussed here. And if they do cause fragmentation and git will be the last to keep the convention, it will sadly have no choice but to bend, just to mitigate further damage.
