Hi Ævar, I agree with pretty much all you said, just wanted to comment on a couple things: On Wed, 18 Nov 2020, Ævar Arnfjörð Bjarmason wrote: > In case I didn't make it clear I have no objection entirely replacing > "master" with "main" in the tests. I just had a practical > concern/question about coverage while it was landing, and a suggestion > of whether perhaps there was an easier/faster way to do the "init" > change first by omitting some of the test churn. > > But if you want to do all the legwork that's fine by me :) I started it, I finish it, I guess. Well, technically Don started it... > I think some of the people advocating this change can rightly look at > some of the previous E-Mail traffic and see what are at best rants and > at worst some political grandstanding that's at best pretty irrelevant > to any proposed changes in git.git. > > But that doesn't mean that there aren't some legitimate concerns. And that's so sad to read. It is disheartening how eager certain people were to drown out others' voices, then claiming that they had not heard any views opposing their own. I mean, yeah, if you want to hear other opinions, it sure helps to stop talking for a while, and to start listening. I consider myself lucky that I _did_ get the chance to listen. Related to my work in GSoC and Outreachy, and through my day job, wonderful people approached me with their stories and perspectives. I am really glad that I had the opportunity to hear those. As to legitimate concerns: yes, you are right. There are those. If your documentation says that you should avoid committing directly to the `master` branch, and then you clone a popular Open Source project and it does not even _have_ a `master` branch, that might be a bit puzzling. Note that I used a clone as an example, not `git init`, because it is a much more common operation. Git is a tool for developers to communicate, in a way, after all, even if it _can_ be used for working in isolation, too. Hence clones outnumber inits. And that communication of ideas, of code, and to combine efforts, to collaborate, that is what Git really facilitates. That is why I find it so important to be inclusive, to be inviting underrepresented developers. There is such a lot of untapped potential there, and even if using a non-offensive default branch name is but a _teeny_ tiny step to open the door a little, it is at least a step in the right direction. Now, since I mentioned `clone`: please note that the default branch name used in a `clone` is squarely outside the Git project's control. It is decided by the maintainer(s)/communities of the respective projects. And that's exactly how it should be. Therefore, as you said before, it does not really matter all that much at what date we will change the fall-back for `init.defaultBranch`. At the same time, I still think that it is valuable to transition the test suite _now_, to be as independent on a specific default branch name as possible, if only to ensure that above-mentioned projects can choose freely what they want their primary branch to be called and Git works just fine. > I do 100% agree that the s/master/main/g change of the default should be > made in one form or another. In my mind that doesn't even require a > consideration of the political motivations at this point as far as > git.git is concerned, just: > > 1. Major Git hosting providers already made the change > > 2. Realistically a lot/majority of git's user base interact with that > in a major way. > > 3. A discrepancy in any default between /usr/bin/git and those > providers is more confusing than not. Right. I originally thought that we should switch the default branch name in v2.30 for that reason, but I now think that adding that advice is probably a less disruptive, and almost equally supportive solution. > 4. #3 doesn't mean they say "jump" we say "how high" whatever the > change is. > > But in this case the default is an entirely arbitrary default. Not > e.g. that they decided to add some ill-thought out header to the > object format or whatever. > > P.S.: Shouldn't the pull patch in d18c950a69f be using the advice > facility, not warning()? I submitted a patch for that, but unfortunately forgot to Cc: you: https://lore.kernel.org/git/pull.795.git.1605781349528.gitgitgadget@xxxxxxxxx Ciao, Dscho
