Consensus on a new default branch name

Hello,

Over the past few days or so, there has been significant discussion [1] and patches [2] about changing the name of the default branch away from 'master' and towards something else.

Concurrently with this, GitHub, GitLab [3], and Bitbucket are working together in order to make a similar change across our respective products. Because of this, we are met with a bit of a challenge: we would like to make these changes before the next version(s) (and so need to settle on a new default branch name), but we also want to avoid a situation where the community is fractured (eg., GitHub uses 'main', Git uses 'default', etc).

A related question is whether or not we plan to change the default value of 'core.defaultBranchName' at all (once Johannes' patches land, of course). That seems to be the intent in [4], but forming consensus around this would be good, too.

So, I would like to form some consensus here as to what the new name should be, if that is something we're committing to doing. This way, we can make this decision now (and allow hosts to make their corresponding changes) while still giving us on the list some time to work on the implementation across one or more release boundaries.

My interpretation thus far is that 'main' is the planned replacement for 'master'. Consensus seems to have formed around this name [5], but if that's incorrect--or there are yet-unvoiced opinions that you would like to share--now is the time to discuss further.

Thanks, Taylor

[1]: https://lore.kernel.org/git/CAOAHyQwyXC1Z3v7BZAC+Bq6JBaM7FvBenA-1fcqeDV==apdWDg@mail.gmail.com/ [2]: https://lore.kernel.org/git/pull.656.v2.git.1592225416.gitgitgadget@gmail.com/ [3]: https://gitlab.com/gitlab-org/gitlab/-/issues/222204 [4]: https://lore.kernel.org/git/nycvar.QRO.7.76.6.2006111610000.56@tvgsbejvaqbjf.bet/ [5]: https://lore.kernel.org/git/nycvar.QRO.7.76.6.2006091126540.482@ZVAVAG-DN14RQO.ybpnyqbznva/

Just correcting an incorrect 'Cc:' for James Ramsay, which I am fixing in this email (and for anybody who replies to it).

On Mon, Jun 15, 2020 at 02:57:22PM -0600, Taylor Blau wrote:

Thanks, Taylor

On Mon, Jun 15, 2020 at 03:21:54PM -0600, Taylor Blau wrote:

My biggest concern here was trying to understand what could break. Having read the patches from Johannes and thought about it a lot, I have a pretty good handle on where Git itself cares about the name. And I feel pretty confident that we can make the change in a way that won't cause problems there (and in fact, I think some of the code will be made more robust by relying on HEAD more appropriately).

There's a more open question of what _else_ will break in the ecosystem. I.e., what other tools and scripts did people write "master" in that we'll never even see, and they will eventually need to update. And there I think we need to be respectful of our users and their time. Obviously stopping at configurability is the least risky thing there. But it's clear that a lot of projects are interested in changing their names, so tools will have to deal with a world where various repos will have different HEAD names.

By moving the default, we do push some repos into a name change that might otherwise have remained oblivious (e.g., if your org has a custom script that nobody else will see, and nobody in your org has an interest in changing their repo HEADs, you might never need to update your scripts). We can help with that by:

  - clearly communicating the timetable for the change, and giving lots
    of opportunity for people to consider whether their scripts might
    need updating (again, I think in many cases these updates actually
    make the tools more robust)

  - giving an escape hatch to restore the old behavior, which Johannes'
    patches certainly do

Both of which I think everybody is on board with. I won't claim that changing the default won't cause _any_ disruption, but it seems to me to be on par with other changes we've made (and is being handled similarly carefully). So I think I'm in favor.

My opinion is that "main" is the best suggestion I've heard.

-Peff

On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:

Jeff, where do you get your statistics? github, for example, have around 100 million repos. How many of them want to do it?

I have a better suggestion, imho. Let's make "master" a default name. Thus:

1. we willn't break utilities and user hopes; this is a backward compatibility.
2. we will see how many projects really need this "feature".

I think backward compatibility is a reasonable and useful thing. And if this is not a political-driven changes, i see no technical reason to not do so.

On Tue, Jun 16, 2020 at 05:52:52PM +0300, Oleg wrote:

Not statistics, but anecdotally, many major projects and communities have expressed interest in switching. Some of them are listed here:

  https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/

I don't think 100 million is the right number to think about. Many of those aren't active, or aren't collaborative. A project like Chrome changing their branch name has a much bigger impact than somebody's homework repo with three commits.

I was curious about some raw numbers, though, so I picked a random sample of ~25k GitHub repositories that had been pushed to in the last 30 days. About 6% have a default branch name besides "master". There's a long tail of names. "develop", "dev", and "development" were the most common (and likely have been that way for a while due to documents like git-flow). Only about ~0.12% were "main" right now, but that name has also only been discussed for about a week.

But it seems to me that with 6% non-master names, most tools are going to run into these cases sooner or later, and have to deal with it. I'd be much more worried about one-off scripts that see a small, non-uniform set of repositories.

I'm also worried about documentation. There's 15 years of information floating around the Internet that mention "master". But it would certainly not be the first time that documentation has bit-rotted. There's a human cost there. On the other hand, some people have expressed that "main" might be more clear than "master", baggage aside, so it could be an improvement in that sense. I don't have an opinion there, having internalized Git's terminology many years ago.

I think it's clear that this _is_ a politically-driven change. It is not helping the software in any technical way to change the name. The question is whether the more abstract benefits to people are worth the potential costs.

But I don't think anybody has been able to quantify the benefits in a meaningful way. Or at least a way that everyone agrees on.

-Peff

On Tue, Jun 16, 2020 at 12:00:05PM -0400, Jeff King wrote:

This is not "many", Jeff :-D. There is info just about *few* major projects (i counted not more than *15*!), that also politically biased and are intimidated.

Jeff, this is a discrimination ;-). And no. This isn't right. How many repos on github is inactive? May be 20 millions? Add to 80 millions gitlab and all another git repos from the world. I think we can easily collect around 150-200 million of active repos. Do you really think that count of developers of these all projects be less than count of Chrome developers? Why do 15 projects (politically biased) outweighs 200 millions of projects? Is this example of democracy or rationale mind? May be some there is corruption :-)?

I think if you get repos from, for example, february instead of *last* 30 days, then you will get a yet little numbers. Because the last 21 days people are insane, if you understand me.

And even so - 6% :-D. Jeff, this is really needed thing! :-D This small numbers show just about one thing - this is useless feature. Of course, i talk about normal people. In any time, there are a few "not ordinary" persons and jokers.

Look, now this is a problem of rare "geniuses". Why do you want to bring these problems to all of us :-)? What did we do you?

Yes. You are absolutely right.

Of course, not. This is obvious.

Jeff, everything is simpler. You lie to youself about it :-). *Everybody* adequate person will say you that there are *no* benefits at all. Only troubles, troubles and troubles. And we are already seeing this. There is no need for a time machine. This will helps nobody. This changes willn't materialize food for homeless and willn't protect someone from humiliation. But in current time, when people click "like" button instead of doing real things for others and think that they do "everything right" and this helps somebody :-), this is hard to understand. If you would find any slave which is offended by "master" word, then this conversation was meaningful. But now it looks like people who have never been masters appologize to people who have never been slaves. And are doing this, note please, in very strange manner.

Look, if you really try to make somebody life better, just image that you have no access to git code. How can you help? Search the better way that will really helps somebody. Don't break git. And after several monthes, when common sense will return to us, we will look again on this "useful" change.

On Tue, Jun 16, 2020 at 08:11:01PM +0300, Oleg wrote:

Oleg, that doesn't make it an invalid discussion point. If Git was written in German and the lead branch was called "refs/heads/fuhrer" (German word for "leader"), you'd be on the opposite side of the barricades arguing that this needs to be changed because it's offensive to many people whose immediate family members died in WW2.

And someone else would be reasonably pointing out that "fuhrer" doesn't mean "The Fuhrer" and nobody is even alive since then anymore, and omg, why is this even a discussion topic -- isn't there something more important everyone could work on?

Yes, it's a politically motivated change, but it's clearly important to quite a few people right now and their views should not be disregarded.

-K

On Tue, Jun 16, 2020 at 01:32:27PM -0400, Konstantin Ryabitsev wrote:

No. You are wrong here :-). I'm adequate person and the case about which you talk couldn't happen. The problems could be if instead of "fuhrer" be "AdolfHitler". And these are completely different things. One side is the recist and nazi whose people killed many, very many, people in the world. And another side is a... m... "master"? What wrong with this word?

Wow. I ask just the same question again and again! There are much of work, but we do some strange changes. These changes will generate a lot of troubles to me and other git users/admins. I don't understand why this is happening. And why if some country have temporary internal problems all other world should suffer and have long-term problems. If anybody can't sleep and want do some meaningless action, they can just buy a t-shirt with the text "no masters, no slaves" or "i'm not supporting masters" or something like this. This will be meaningless like a default branch name change, but nobody will suffer.

Ok. But why my and other views are disregarded? Why are this people better, then we? Who decide this? Why do we have a such discrimination in 2020?

This is a stupid politically motivated change and in the future something can happens again and somebody run to change something meaningless else. That why software should stay away from politics. Software is just an instrument. And we shouldn't break an instrument everytime something not technically related happens.

But this is ordinary western chauvinism. And intresting thing. People which try to looks like anti-racist behaves like a racist:

they just do something with public tool without discussion with anyone outside of their elite circle.

At first nobody asked indians about their land and desires. First americans just killed almost all of they. Then, americans went to Africa and made slaves from locals. Europian countries went to Africa and Asia and made colonies with cheap labor. Hitler didn't ask anybody about the desire to be killed - just did it. And now the descendants of slaveholders break public tool without asking somebody.

Years are coming, but nothing changes...

https://www.change.org/p/github-do-not-rename-the-default-branch-from-master-to-main https://www.reddit.com/r/github/comments/h8u7fo/github_to_replace_master_with_alternative_term_to/

On Tue, Jun 16, 2020 at 08:11:01PM +0300, Oleg wrote:

I didn't count them. 15 who have already said they are interested does seem like "many" to me, especially as I'd expect more to do so as the issue gets more attention. I don't think it matters if they're politically biased or not. I just said they expressed interest in switching.

But anyway. You asked what I based my statement on. I told you.

Please stop making strawmen. I never said that the number of Chrome developers was higher than the number of other developers. The original claim I made that started this portion of the thread was only that projects have expressed interest in changing, so tools are going to deal with seeing non-master branches (and in fact already have been).

Again, my point wasn't that a majority of people have changed or even would change.My point was just that a significant enough percentage of repos use the non-default name that it's a thing tools will need to deal with. Perhaps you think 6% isn't enough to say so, but we may just agree to disagree there.

You're asserting your position without providing any argument here. Clearly other people feel the opposite way.

To be honest, I am not sure if it the benefits outweigh the costs or not, and I am skeptical that any kind of accurate data gathering (e.g., a poll of opinions) could be done at this point, both because of the vagueness of the task and because the issue has become so charged (not just within Git, but in the greater world). But I'm inclined to err on the side of empathy, especially if we can keep the cost side relatively low.

-Peff

On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:

What if we work on making this configurable for now, but stick with the legacy name until we introduce breaking sha1 changes? Almost everything will need to retool for those anyway (and all documentation rewritten), so it is reasonable to bundle these changes to happen at the same time.

-K

On Tue, Jun 16, 2020 at 12:10:01PM -0400, Konstantin Ryabitsev wrote:

I wonder if allowing the buildsystem to set this default value would be a wortwhile stepping stone. This way we can test things in different ecosystems.

Thoughts? -Santiago

On Tue, Jun 16, 2020 at 12:13:31PM -0400, Santiago Torres Arias wrote:

If you mean allowing "make DEFAULT_BRANCH_NAME=foo", that seems reasonable to me. Though the tests likely wouldn't run in that case (unless we are planning to leave the test-environment-munging bit in place forever, I suppose).

-Peff

On Tue, Jun 16, 2020 at 12:10:01PM -0400, Konstantin Ryabitsev wrote:

I think that's a potential timetable we might use. It would be easier to consider if we actually had a timetable for the sha1 changes. :)

But I certainly agree that if the timing works out favorably, switching both defaults at once, with a big version number bump, would be nice.

I do think that the branch name change will have more far-reaching effects on documentation than a hash change. Mostly because hashes are random-looking garbage from a user's perspective anyway. So aside from people dealing with hash transitions, we'll mostly just need to update any hard-coded values in tutorials, examples, etc. Whereas I think the word "master" creeps into a lot of more substantive discussions as a synonym for "the main branch".

-Peff

+1 - that will also allow for a more social influence on the other tooling in the ecosystem. Projects new and existing will start to adopt a name, and that will be surveyable.

On Tue, 16 Jun 2020 12:10:01 -0400 Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

Makes perfect sense to me. No reasonable person can argue against giving individual repository owners the ability to *easily* call their "primary" branch anything they want.

This flame war plus the publicity it generated lets everybody know that someday, whether in 1 month or 5 years, the default will be something other than "master", so they'll start changing their software and scripts to accommodate a variable instead of a hardcode, so when the change happens, there will be minimal software disruption and minimal hurt feelings.

SteveT

Steve Litt 
May 2020 featured book: Troubleshooting Techniques
     of the Successful Technologist
http://www.troubleshooters.com/techniques

On Tue, Jun 16, 2020 at 01:44:49PM -0400, Steve Litt wrote:

This is great. But

this is not. Damn. Did you see what people say here? Why are you even forcing people to do this? Just stay "master" as a default and everyone will be happy.

On Tue, Jun 16, 2020 at 10:31:07AM -0400, Jeff King wrote:

See also https://lore.kernel.org/git/20200616210701.22924-1-zeevriend@gmail.com/

On Wed, Jun 17, 2020 at 08:06:17PM +0200, Michal Suchánek wrote:

So you completely ignore this input.

That kind of gives confirmation to the naysayers that point out this is not really about inclusivity but about US-internal politics.

If that is so be more honest and clearly say that by being based in the US you must give way to certain activists or be potentailly subject to terrorism from the same or more radical colleagues of the activists that request the change.

Thanks

Michal

On Wed, Jul 01, 2020 at 07:31:08PM +0200, Michal Suchánek wrote:

I didn't ignore it. I just didn't have anything useful to add after reading your email.

If there's a potential problem with "main", I think it's worth considering. But I have a very difficult time figuring out how to consider all of the inputs. Personally, I don't find "main" to be a problematic word. It has no other connotations in my personal experience. But then the same is true of "master" as well.

Anybody in a similar position who is working on the project and might need to form an opinion about which default word to use has to rely on input from others. The email linked above is one data point. There are other data points arguing that "master" is bad.

In an ideal world, we'd have a name that has no data points at all arguing against it. But I'm not sure how feasible it is to accommodate everybody. There seem to be enough data points arguing against "master" that I can believe there's a non-trivial number of people who would like the default changed to something else[1]. I had wondered if other people might speak up against "main", but I have not seen anyone do so (neither here, nor in other forums where the name "main" has been discussed). That doesn't invalidate the opinion of the author above. But if we have to choose something from among an imperfect set of options, then that may involve picking the least-bad name.

I am open to the argument that the very people the author suggests might be bothered by "main" might also not be well represented on this list or in other forums discussing the change. It would be helpful if any proponents of that argument could try to gather some evidence.

I'm not sure what constructive action you're asking for here. The link to the email above suggests that you might be arguing for a different alternative besides "main". If so, please suggest it (or if you did elsewhere already and I missed it: sorry, please repeat it).

If your point is to argue "you care about master but not about main, therefore you're a hypocrite and we should change nothing". Then one, I do not agree with that characterization, and two, I don't think that's a very helpful addition to the conversation.

If you meant something else, please help me figure out what it is.

-Peff

[1] I'm also open to the argument that the number of data points arguing
    against "master" are inflated by well-meaning people who claim to
    speak on behalf of others. But it seems very hard to me to collect
    useful data on this kind of thing. My personal feeling is that it
    makes sense to err on the side of empathy where it's practical to do
    so.

Peff,

With all respect I have yet to see any evidence actually presented against master either. The original list makes the claim its offensive and everyone I have asked on other forums just says its obvious its offensive but cannot say how it is without resorting to `Do you not find enslaving humans offensive`. About all we have is twitter where you can easily find people saying its time to go and that changing it makes them feel worse as they had no problem with it and yet its being forced through in their name. L makes a case with research that the initial claim was also not made in good faith at https://lore.kernel.org/git/20200621195023.3881634-1-lkcl@lkcl.net/ . The link is also more on the master/slave depart but many of the points researched cover this one as well.

I like that you want to err on the side of empathy but based on how most of these changes have been forced through their communities I do not think the ones arguing for this would do the same for you. As can partially be seen with the claim that there is no amount of work that can justify continuing to use master or a host of other terms.

My personal feeling is it should not change as while many on this list certainly are speaking in good faith and want to help the momentum behind the change very much is not. While I know its not part of this list check out the gitlab issue where they finally opened it back up for discussion at https://gitlab.com/gitlab-org/gitlab/-/issues/221164 and it adds onto those that seem to argue for attack any who argue against. If a change is going to be made that will affect million of developers and possibly break thousands to millions of applications  I would say that you need a mountain of proof and not what has been seen so far.

If I may ask what is the intended result of the change if it cannot be measured?

-Whinis

On 02/07/2020 13:21, Whinis wrote:

The earliest claim I can find is from 2003, verified at Snopes in 2007 [1] and reported in 2003 at [1] (and elsewhere)

I would not expect that the original complaint had been withdrawn. I don't know if the relevant US/local laws have changed.

A recent blog post on racial bias in AI [2] highlighted that "Algorithms are our opinions written in code",  just as many of our naming conventions are implicit stand-ins for unsurfaced opinions and biases.

One area that is far more obvious in the UK, is the use of euphemisms and innuendo, which can be grossly misused. It is quite easy to create subtlety different phrases which actively discriminate that wouldn't be noticed except by the careful or 'in the know' listener.  This can easily be done with 'master' in Git.

From a comment in [3], the link [4] provides details of the association of 'master' with 'slave' in Engineering literature, beginning in 1904 for a pendulum & clock arrangement. In electronic clock circuits it wasn't till 1966 the use extended to flip-flop circuits, while hydraulic master/slave cylinders started in 1959.

Branch names are meant to be ephemeral is the wider Git ecosystem, so Git should be able to allow the user to chose their own default name.

The other issue is that Git doesn't do unique masters anyway. If you have the correct commit hash you have a perfect, indistinguishable replica of the original object - It's not a master (in the old 'version control' sense) any more, so we don't need that name for local clone's branch, unless it happens to be copied as the remote tracking branch.  Though that is orthogonal to this discussion.

As I understand the change process, this will not be the catastrophic change many are suggesting. Existing repositories will still continue working. New repositories will have options for choosing the defaults. The usual level of great care over backward compatibility is being taken. 

Anyway, that's the back story, with references,  that I've been able to track down. Hope that helps.

Philip

[1] https://www.snopes.com/fact-check/masterslave/ [2] http://news.bbc.co.uk/1/hi/technology/3243656.stm [3] https://dev.to/educative/understanding-racial-bias-in-machine-learning-algorithms-4cij [4] Stable URL: http://www.jstor.com/stable/40061475  "Broken Metaphor: The Master-Slave Analogy in Technical Literature "

Not exactly proof in this sense nor proof they had an actual grievance as someone in US law might tell you. Sadly it was rather recently a lawyer would go around claiming to be disabled or speak for an unnamed disabled citizen and sue every single restaurant they came across for ADA violations. Same was done recently with a Lebowits but for copyright law where its easy as a lawyer to sue continuously to get an easy settlement until you are disbarred. Even from that link the official that wrote the memo said

There is a great deal of misunderstanding on the "bias" in AI and in AI in general. I think you may have linked the wrong comment as [2] goes to a BBC story on the same story as the snopes article. However if you are talking about the recent depixelator it was shown to have similar performance if you darkened the images. This is not a bias its a technological limitation as darker images have less contrast on facial features, its also a well known issue in photography where its difficult to get enough dynamic range to properly expose an image with both darkskin and light skin individuals. Outside of extremely expensive cameras that even professional photographers don't want to use the technology is not in the hands of people to take proper photos with the needed dynamic range. This is also why lighting in films and TV are so important.

I feel a great many people want to attribute bias due to lack of data whenever no bias exists.

Unless you are making some allegation that anyone using the word master is racists or that somehow every technical field is inherently racists I have no idea why you are claiming its the same as actively discriminating. Or maybe you are trying to say the UK using its euphemisms is trying to be covertly racists? It would do well to clear up this confusing reference as it currently could be seen as insulting or making implications which clearly do not exists.

I am rather unsure why you are reference either. Maybe you mixed up 2 and 3 because 3 has nothing on master or slave but as you have mentioned its orthogonal since git has no slave branch. 4 is a admittedly short paper as the author recognized that it could be its own doctoral thesis and only did a cursory search although many are using it as proof that no references exists prior to this time. It also adds its own heavy biases as mentioned in the paper while gill was the first to use the slave reference that they can find it was used for many years without much discussion and even when challenged it was determined it would be better than a much wordier alternative because it would be better understood. The paper also claim that Gill would be disapproving of the words use however has nothing to back this up considering they not only used the term but appearntly did so for many years afterwords at lectures.

How does each commit have a perfect indistinguishable replica of the original? My understanding is each commit is a record of changes compared to the last. As such only the first commit is truly 'perfect'

Is it? Because it seems to be that its waved off as a necessary cost of changing "outdated" language.  Being that its been used now for at least 110 years and being that its the understood vernacular and multiple projects and scripts assume, even if wrongly, the master branch is the one you should work from means changing this default is not usual great level of care. Certainly main seem to think its as simple as changing the letter and nothing will break. Sadly that rarely true

Unfortuntely no as the references being asked for is who this change actually impacts. We could go to twitter but that has it owns biases and every issue on this topic outside of this mailing list is either locked or biases by assuming it must change and leaving out master or tainted due to brigading. Just based on what I have anecdotally seen however most of the people pushing for this change is not the affected minority group its claimed to help.

-Whinis

Hi, My key point was to pass on the references. I appreciate that US law is a bit peculiar (to European eyes).

On 02/07/2020 22:59, Whinis wrote:

The point there was that it was, at the time, a complaint that had a response which was passed into the community.

My error in failing to renumber that correctly.

Today an article highlighted the issues and difficulties with data sets: https://arxiv.org/pdf/2006.16923.pdf

It's the *misuse* that's racist

Racists in the UK (and elsewhere) do use euphemisms and subtleties to perform "vicious signalling".

The original US case was with reference to the joint use of master-slave. That Jstor article may be behind a log-in wall, so I extracted from the essay, for immediate readers, some of the initial uses of that term pair in engineering.

Your a08a83db2bf27f015bec9a435f6d73e223c21c5e, my a08a83db2bf27f015bec9a435f6d73e223c21c5e, https://github.com/git/git/commit/a08a83db2bf27f015bec9a435f6d73e223c21c5e : Which is the "master copy"

It's that Git is *distributed*, rather than a single central source of truth that old version control systems used. I remember the smell of blueprints, and of kaolin & linen master drawings (unique works of art, protected and valued). That has all gone. It now a case of validating the copy you have same hash. The chain of evidence has reversed.

Gits choice is only 15 years old.  There have been other changes to Git, and the forthcoming hash change is much more of an 'impacts everyone' change. Any direction of travel always includes some changes, generally for the better.

Most progress comes through imperceptible changes, made in the appropriate general direction.

Philip

Right but as is the case here of a likely either malicious requests or an offhand comment leading to disproportionate response just as I believe this started due to a wallstreet journal article inflating a pair of terms used for over 100 years as racists simply due to being used.

Are you saying using the word master is racists? Are you aware of the origins of the term and how far back it goes? or that mister is also a mutation of the same word? Cause that a rather high bar to state considering its use not just in programing or engineering but also things such as master degree and master copy. Its also rather odd considering that suggestion that master alone is racists from what I can tell started only with this git issue.

That's fair, I have a university subscription and have seen that article a few times. Its ultimately a first pass article that someone could take further but should in no way be used as proof that this was the first use of this pair. Also the pair does not exists in this case so its a rather odd citation.

Sure, how does that impact the use of the word master? its the branch name as in the branch, as described by the person that picked the name, of the master copy. Git being distributed has nothing todo with the branch

Framing moving large sections of words out of use that have been in common use for at least 100 years in a technical sense and has no racial connection or common racial usage seems a rather odd thing to consider progress. I would view people developing non-existent connections between words just as the snopes articles showed is a step backwards and shows a lack of education on words. If you first  thought with seeing a word is how can it offend someone it might be difficult to work around. If anything you are inflating problems that don't actually exists.

-Whinis

Michal Suchánek wrote:

I've done enough research to know that even within the context discussed in that message, this is not what comes to mind when the word "main" is used.

That said, the approach so far in the Git changes discussed here has been to focus on configurability. We don't only have to care about defaults: we also need to make sure Git is adaptable enough to work well with branch names that fit the needs of particular Git-using projects (whether that's because they use a different language than English or because they have chosen branch names that reflect their workflow, or for other reasons entirely).

Thanks and hope that helps, Jonathan

On Mon, Jun 15, 2020 at 02:57:22PM -0600, Taylor Blau wrote:

I've been refraining myself from commenting (specially with so many
passionate voices on [1]), but I'm happy that this is happening. While I
personally don't see anything offensive in 'master', I think it's
worthwhile to try to accomodate more people in the community. As always,
it's harder to identify what is bothering a particular group if you are
not part of that group. Kudos to the community (and to you Taylor) for
trying to move this topic forward in a constructive fashion.
 

I'm not familiar with how formal consensus is built in this community, but take this as an explicit +1 from me.

Cheers! -Santiago

On Mon, Jun 15, 2020 at 2:01 PM Taylor Blau <me@ttaylorr.com> wrote:

As I stated in the other thread[1], I'm happy 'default' isn't winning because I think it can lead to ambiguity about the meaning of the phrase "default branch" (particularly when someone changes HEAD on the server to point to anything other than "refs/heads/default"). I don't think "main branch" poses similar issues, as it's not a phrase I've seen used that much (in contrast to "default branch"). Also, "default" being ambiguous bothers me personally more than other terms being ambiguous, as per my story in the other thread. However, it's possible that there is documentation or guides somewhere that have used "main branch" in the past and could become ambiguous with the proposed change, and thus would benefit from updates.

In fact, just to verify, I did a quick search of the git codebase and found 38 uses of "default branch". There were also 9 uses of "main branch", but almost all of those were actually referring to a CVS repository and importing from there which I find innocuous. There was one in git-log.txt that looked problematic to me, though -- it should probably be reworded when we do the master->main renaming.

Hope that helps, Elijah

[1] https://lore.kernel.org/git/CABPp-BF8vo_fCbM1ct0MYFhQcVmPwfq7_Q3Fd+SnM0=gVmxkrQ@mail.gmail.com/

On Mon, Jun 15, 2020 at 03:38:08PM -0700, Elijah Newren wrote:

Thanks for writing this out (I'm still catching up on list email after a vacation, so I missed the earlier thread). It really cemented for me that "main" is better than "default".

-Peff

Jeff King <peff@peff.net> writes:

In any case, it makes sense to use separate words for the concept ("default" --- as in "the name given to the first branch created in the repository by default") and the actualy value chosen for the entity (master or main in this case).

The statement:

    I configure in ~/.gitconfig that the default branch name for all my
    repositories to be 'main'

is much easier to read than the last 'main' replaced with 'default'.

On 2020-06-15 at 20:57:22, Taylor Blau wrote:

I think "main" is a fine choice.

On 16 Jun 2020, at 6:57, Taylor Blau wrote:

Avoiding inconsistency is definitely front of mind for me.

Based on informal surveys internally, and polling on https://gitlab.com/gitlab-org/gitlab/-/issues/221164, ‘main’ seems to be the preferred option. Using GitLab’s MECEFU (Mutually Exclusive, Collectively Exhaustive, Few Words, Ubiquitous Language) [1] approach to naming I think ‘main’ ticks all the boxes. None of the other proposals seem as clear.

I think Elijah’s points in other messages about the problems of ‘default’ are particularly helpful. I would prefer to avoid that name.

Thanks, James

[1]: https://about.gitlab.com/handbook/communication/#mecefu-terms