From: Junio C Hamano <firstname.lastname@example.org> To: Konstantin Ryabitsev <email@example.com> Cc: Brandon Casey <firstname.lastname@example.org>, "Theodore Y. Ts'o" <email@example.com>, Lukasz Niemier <Lukasz.Niemier@kobil.com>, Felipe Contreras <firstname.lastname@example.org>, "brian m. carlson" <email@example.com>, Git <firstname.lastname@example.org>, Johannes Schindelin <Johannes.Schindelin@gmx.de>, Don Goodman-Wilson <email@example.com> Subject: Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco Date: Thu, 19 Nov 2020 13:25:27 -0800 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> (Konstantin Ryabitsev's message of "Thu, 19 Nov 2020 08:37:05 -0500") Konstantin Ryabitsev <firstname.lastname@example.org> writes: >> So we're changing the default branch name from "master" to "main"? > > To my knowledge, there are no concrete plans to change anything at this > time. All recent work was to remove any special-case treatment of > "master" as the default branch name, so people are free to use any > configuration they like. That is a fair description of one state which is a bit stale. All recent work has been to make sure our tests will not lose test coverage when we decide to change the fallback default value for init.defaultBranch to a value other than 'master'. In other words, we have been talking about changing (or not changing). The question most useful to ask at this point are to what name (fixed? computed?) and what the transition plan would look like. >> For what purpose? What problem are we trying to solve? > > People want to be able to use arbitrary branch names. What you gave was the purpose of init.defaultBranch we've introduced in the last release, but that does not answer the question you are answering. The discussion thread you posted to, however, is already talking about changing (or not changing) the fallback default value for that variable, i.e. what name does the initial branch get upon "git init" for end-users who do not indicate any preference. Some understand well that the primary reason to switch to 'main' is to help people who will need to interact with projects and hosting providers that have done the same switch already [*1*]. Some do not buy that reason well and ask "why?". You need to give an answer to the latter. >> Is the word "master" now going to become a taboo word that we're all >> afraid to say? > > No, everyone is welcome to use it if they like. It has perfectly > legitimate usage cases -- for example, some of the staunchest opponents > of this terminology continue to list their "Master of Arts" degree on > LinkedIn. Correct. >> Isn't this all a little silly? What's wrong with the term "master"? > > It is misleading in the context of git, because it implies that a branch > carrying that name is in some way special compared to other branches > (e.g. like "trunk" in the SVN world). In reality, the "master" branch is > just a branch like all others (and can be missing entirely or have junk > in it), so it really shouldn't be called "master". I find the above answer even more confusing, in the context of major projects and hosting sites all moving to 'main'. If 'master' is misleading for all the reasons stated in the above paragraph, 'main' would equally be misleading. In other words, "It is just a branch like all others, so it really shouldn't be 'master'" leads to "it shouldn't be 'main' or 'primary', either". I personally am fond of this line of "let's not treat one single thing any special among others" thinking, but I think the way people use the initially created branch tends to make it special at the end of the day. While the project is still in its infancy, you may use that as the only branch until the tree of the project starts to take its shape, perhaps with subdirectories dedicated to sources, documentation, and overall build procedure, etc. Then you may start to fork different branches off of it to work on topics that last more than one commit's worth of time. At that point, it is likely you'd use the initially created branch as the primary integration branch, until you start to need the second and third integration branches. Like it or not, the primary integration branch would inevitably end up being something more special than others, and it is likely that using the initially created branch for that purpose would be the most convenient. There however may exist two or more equally significant branches, not just one special one, though, but it is reasonable to have at least one special one. And for this reason, it does not make much sense to change the fallback default to "unnamed"---that would force everybody to immediately rename it (or set init.defaultBranch). [Footnote] *1* We expect many projects end users would interact with to be using 'main' as the branch of primary interest, and cloning from such a project would give you 'main' (i.e. "git clone" finds what name the other side users, and uses the same name locally). If a new user is starting their Git experience from scratch in such a world, it would be more helpful if their "git init" placed them on the 'main' branch, and their hello world project built on that single branch is pushed to the 'main' branch in their publishing repository at hosting sites'. In such a world, tutorial books will all be written with 'main' as the initial branch name, too, even though good ones would mention that historically 'master' has been used and the readers would see projects with history longer than readers' Git lifetime may still use 'master' as the primary branch.
next prev parent reply other threads:[~2020-11-19 21:27 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-13 0:04 Felipe Contreras 2020-11-13 1:01 ` brian m. carlson 2020-11-13 4:27 ` Felipe Contreras 2020-11-13 5:14 ` Theodore Y. Ts'o 2020-11-13 6:28 ` Felipe Contreras 2020-11-13 14:58 ` Theodore Y. Ts'o 2020-11-13 15:37 ` Felipe Contreras 2020-11-13 16:08 ` Michal Suchánek 2020-11-14 14:19 ` Lukasz Niemier 2020-11-15 3:46 ` Theodore Y. Ts'o 2020-11-15 4:27 ` Felipe Contreras 2020-11-19 1:02 ` Brandon Casey 2020-11-19 4:16 ` Peter Hadlaw 2020-11-19 13:37 ` Konstantin Ryabitsev 2020-11-19 21:25 ` Junio C Hamano [this message] 2020-11-19 23:29 ` Felipe Contreras 2020-11-20 19:14 ` Konstantin Ryabitsev 2020-11-19 21:29 ` Brandon Casey 2020-11-20 0:34 ` Felipe Contreras 2020-11-13 6:09 ` Don Goodman-Wilson [not found] ` <nbCkLegnP_kb-16UzAuDChE0p68ZtRD_3ZN3o3BJHYBYpUxTWuKjvhCSKT7zRZl_sckHrkyJl2fwePFUBR-HtDcEV0rHuac6Ygg-FrrYsYIemail@example.com> 2020-11-13 6:47 ` Felipe Contreras 2020-11-13 13:53 ` Philippe Blain 2020-11-13 15:49 ` Felipe Contreras 2020-11-23 15:39 ` Whinis 2020-11-20 18:38 ` Ismael Luceno
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --cc=Johannes.Schindelin@gmx.de \ --cc=Lukasz.Niemier@kobil.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
email@example.com list mirror (unofficial, one of many) This inbox may be cloned and mirrored by anyone: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V1 git git/ https://public-inbox.org/git \ firstname.lastname@example.org public-inbox-index git Example config snippet for mirrors. Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.io/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ code repositories for the project(s) associated with this inbox: https://80x24.org/mirrors/git.git AGPL code for this site: git clone https://public-inbox.org/public-inbox.git