tl;dr It sounds like you mean well- but that has the potential to break a lot of things that expect the name master, so I’m not sure it’s a good plan.
I am against this as a default for technical reasons, and as an aside because as others have mentioned master is the in the context of a **Gold Master** meaning a product which is ready to ship. I’m sure your intent is well meaning but this does not appear to have the connotations you are ascribing to it. Given that I am against it purely because I see it being confusing and a maintenance/backwards compatibility headache to change.
Someone said you can create whatever kind of _git init template_ you want and I think that is probably the best course of action who continue to take issue with what I think most consider pretty innocuous terminology.
---- Now for the technical problems that could arise from changing such a thing on a whim.
In software there is a concept of a known value which is expected to exist for min(lifetimeOfProduct,HEAD_DEATH_OF_UNIVERSE), and no matter how much you want to get out from under it you always have unforeseen consequences. It’s not quite as strong as a hardcoded constant, but it’s effectively a convention everyone follows kind of like a system’s environment variables.
In this case I can already see a few things that will go wrong:
1) Any utility that augments git and treats master as a special default branch (regardless of the note in the docs that there is nothing special about master except that it is created by default) is going to break or need to be reconfigured.
1A)There are infrequently modified code bases with small teams that will have to unpick this,and may do so slowly causing their package to be semi broken for some time
1A.1)Any codebase which pulls dependencies form those repose will cascade into failure. goto (1A)
2)Any automation written by a user which expects the branch master to exist will break. 3)People who have already checked out the master ref may accidentally cause a divergent master history as habit causes them to merge into master rather than say main. 4)Any documentation of git either in official git documentation or in professional training materials will become considerably more confusing to new users as there are at present 15 years of archived documentation that refer to this branch as master.
We run into this kind of issue in software all the time, which is why you see packages like PHP deprecate interfaces… but then still need to keep them around for decades, simply out of fear of how much would break if they actually took them out.
Probably there will be more issues that we can’t predict without testing it (which again I am personally against doing unless it’s you’re own repo with your own template and your own rules).
It will probably be a maintainability nightmare that isn’t worth the fuss and I don’t even want to think of the aggregate lost man hours.
