On Wed, 17 Jun 2020 at 22:17, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > Jonathan Nieder wrote: > > Junio C Hamano wrote: > >> demerphq <demerphq@xxxxxxxxx> writes: > > >>> kind of confusion. Consider how this conversation goes for us: > >>> > >>> A: "No you need to fetch trunk from the remote, then you need to merge > >>> it to your local trunk and then push it to the master trunk". > >>> B: "Ok." > >> > >> Hmph, why isn't the last one "trunk trunk"? > [...] > >> What I am trying to get at is, after changing the name that is given > >> by default to the primary branch in a newly created repositories by > >> "git init" to 'main' (which I am OK with, and it seems that the > >> major projects and repository hosting services will be doing anyway > >> with or without getting themselves in this discussion on this list), > >> wouldn't we risk the same "master master" confusion caused by and to > >> those newer users who learn 'main' is the word given to the primary > >> thing? > > > > I think Yves's point is that when the tool you are building has a > > component named $FOO, it's confusing to also have a branch named $FOO. > [...] > > In particular when building distributed systems, historically it has > > been common to have one of the components being built be named > > 'master'. > > Of course I missed the other point --- hostnames like master.<domain> > (e.g., a hypothetical master.kernel.org), refering to the source of > truth for something that then gets replicated. > > I don't think we're likely to see hostnames like main.kernel.org > because it's just *so generic* as a word. Yep, you summarized my point well. I would say master.kernel.org is a correct use of the term "master copy", and the use in the branch name is simply not. My "master branch" for git.git is NOT *the* master. It doesn't make sense to call something "master" and say it means "master copy" when there are actually multiple copies of the master. That isn't what "master copy" means. So I would say that since in practice very often there will exist a repo which is considered to be *the* master copy of the repo having "master" as a default branch name is unhelpful. And as you say "main" does not have this problem to quite the same extent. Although frankly I could see "main" being a common term in more distributed development processes where there might not be the same concept of a "master" repo, but there might be a "main" repo where people commonly share their work. Ultimately if I was the decision maker here I would be choosing terms that are as workflow agnostic as I can find. "main", "master" and "primary" are not workflow agnostic, they are if anything a bit workflow opinionated. "trunk" on the other hand seems pretty self-descriptive and doesn't have much baggage. It's bark is worse than its byte however. :-) cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
