On Wed, 17 Jun 2020 at 21:56, Junio C Hamano <gitster@xxxxxxxxx> 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 described was someone pulling from a box they have code on (which does not have access to the master repository) to the local repo on their laptop so they can push it to the master repo. We have a master repo at $work. We use a mixture of centralized and decentralized dev models. To get your code into production it must hit the master repository, and it must be in the trunk branch in the master repository. I imagine this is a relatively common configuration, and problem in a professional context. Eg, I might be testing or debugging code on a node that is not allowed write access to the master repo for security reasons, so I need to pull the code from there to my local workstation and then push from there to the master repository. And all too often our people don't use topic branches for this stuff and just hack on their local copy of trunk. So from my point of view what I said was absolutely correct. > > Similarly when the perl project migrated to git we renamed "master" to > > "blead" to reduce the possibility "master master" confusion. > > Or put it differently, "your local master? remote master? or the > primary master?" would be a way to state the phrase A asked in the > example without renaming the name for the primary branch to 'trunk'. Well, "primary" is not a terrible replacement term for "master", but it isn't ideal either, as it also suggests the existence of a usable secondary, which isn't a correct mental model (for us). Personally I would eschew "primary" when there isn't a "secondary". > 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? Yeah I think it will still cause problems. If it was my call I would not choose "main" either. Having said that I do think it is a bit better than "master" however, as it leaves the term "master" unambiguously about repositories, and it leaves the term "main" unambiguously about branches. Also I would argue it is more etymologically correct. I would argue that the "master" branch in git terminology is NOT really the "master" unless it is in the "master" repository. "master" in the content of "master copy" implies "one" (it has to, what do you do if you have two masters and they aren't the same!), but using it in a distributed sense for a branch name doesn't imply one, it implies many, so it really doesn't make a lot of sense. > Wouldn't you teach your users to fetch 'main' from the remote, merge > it to the local 'main' and then push it to the 'main' main? Unfortunately we call our main repo "main.git", so for my workplace "main" as a default branch name would be suboptimal. We chose "trunk" because "main", "master", "primary" all have these double meanings. On the other hand "trunk" is the standard word for the things that branches grow out of, and in some trees, the branches even can merge back into the trunk![1] Thus I find it weird it isn't perceived as the "obvious" choice to solve this problem. That the bulk of the population chose "main" suggests to me a lack of imagination more than a reasoned and thought through decision. Anyway, personally I would say "main" and "master" are both bad choices for the default *branch* in a tool that is as workflow agnostic as git is and seems to intend to be. It is relatively unfriendly to scenarios where there is in fact a "main repo" or "master repo" . Many people will in practice use git in a relatively centralized way with at least one repo designated the "main" or "master" repo for the project, and so you end up with two "master" or two "main" things that are very different with very different properties. So yeah, I would say that "main" is slightly better than "master" but is still suboptimal from a comprehension point of view, and it is downright unhelpful for my $workplace (but I recognize that isn't a problem you should be considering in this discussion.) Thank you for your time and efforts in dealing with this subject. cheers, Yves [1] https://www.reddit.com/r/mildlyinteresting/comments/25xkg2/a_tree_branch_grows_back_into_the_tree/ -- perl -Mre=debug -e "/just|another|perl|hacker/"
