On June 15, 2020 3:38 PM, Sérgio Augusto Vianna wrote: > Subject: Re: Rename offensive terminology (master) > >But the people that contribute to the code and to an open-source project > are the owner of that project so they get to get the calls. > > Ignoring everyone else's opinions and needs and just exerting your authority > is the very definition of authoritarianism. Yes, they do have the right. But if > they ignore the users, they can just use a fork that does what they want. > Have anyone considered that a breaking change in git might very well result > in a fork? Without seeing the whole context of this response, I will answer simply as a repository manager, not a platform maintainer. While I fully understand the requirement to change the term "master" (and I think it should be changed), the situation must be put in the context of the available technology. In all major players, whether git itself, or GitHub, BitBucket, GitLab, or AzureGit (there are probably others, but I'm trying to cover 95%-ish), the repository manager/owner has the freedom TODAY to change the default branch to anything they want, within the limits of the character set encoding and name contents. No change in code is required to make this change in one of your repositories. Action is required, some configuration, but it is not a difficult or lengthy activity, to change the default behaviour. As happened with Jenkins as an example, I expect that the community will handle this change over time as is practical to cover all the (previously mentioned hundreds of) touch points without braking the one DVCS that manages much of the current set of production operating system code (a.k.a. git). My team still has a just few legacy repositories that still publish "master" as the main branch because if the impact on our deployment infrastructure - which is critically customer facing. We will address them when we can do that without impacting customers. But we are standardizing to a more GitFlow approach with "development" and "release" as our main branches and "bugfix/*" and "feature/*" as topic branches - with "development" published as the main branch. That is our choice. You can do something similar as technology stands today in the git ecosystem. I cannot comment on OpenSource or commercial git clients who might have limits on their own naming standards, but the bulk of them should be agnostic to the published default name. However, scripts that use git (and there are a huge number of those) should also respect the default branch as published without hard-coding the term "master" to allow us repository managers to seamlessly change what we publish for our communities (yes, I am guilty of not following my own advice today looking back historically because I did not know better some 8 years ago). With Respect, Randall
