Hi Johannes (and Dan) On Wed, Jun 10, 2020 at 09:19:21PM +0000, Johannes Schindelin via GitGitGadget wrote: > A growing number of open source projects aims to avoid the branch name > master due to its negative connotation. See [1] for an existing discussion > on this. The links [2], [3], and [4] describe community-driven ways for > users to rename their default branches or use template edits to set a new > default branch name. > > [1] > https://lore.kernel.org/git/CAOAHyQwyXC1Z3v7BZAC+Bq6JBaM7FvBenA-1fcqeDV==apdWDg@xxxxxxxxxxxxxx/ > > [2] https://twitter.com/mislav/status/1270388510684598272 > > [3] > https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx > > [4] https://github.com/ethomson/retarget_prs > > By necessity, existing repositories require a lot of manual work to move > away from that branch name, but it should be much easier for new > repositories. This is (somewhat) orthogonal to the topic here, but I wonder if we could be doing anything to make this easier for users. Could servers remember that a branch has ``moved'' and alert users as such when they pull? Even better, it would be nice if this alert from the server could allow clients to automatically rename their refs appropriately so that this transition is as easy as possible, even for existing repositories. > This patch series allows overriding the branch name being used for new > repositories' main branch. The main way to do this is the new > core.defaultBranchName config option. This first patch was contributed by > newcomer Dan Goodman-Wilson. Thanks for the contribution! Welcome, Dan! This is a fantastic first contribution, and I would be honored to help and move this forward in anyway that I can. I should note that I am technically "out of office" (which normally wouldn't mean much, but this time means that I am on a road-trip, and so am only at my computer infrequently). I am catching up on just a few emails here, but I'll be able to help out more (and would be honored to do so) once I am really back next Monday. > The other patches follow other places where "master" is hard-coded and use > the new git_default_branch_name() method to consume the config option before > falling back to "master". > > The last patch updates documentation only after the config option is ready > to apply to all of these scenarios. > > This series DOES NOT change the default automatically, but only provides an > opt-in mechanism for interested users. It also presents a way forward for > such a transition, if and when we decide to do so. Specifically, the new > GIT_TEST_DEFAULT_BRANCH_NAME environment variable could be used to update > test scripts on an individual basis instead of all-at-once. Provided that the eventual plan is to seriously evaluate a name other than "master", I think that this is a good way forward that clears the way for us to make this change easily, without forcing us to come to a conclusion on what name will replace "master" today. For what it's worth, I am completely in favor of abandoning this term. My colleagues at GitHub (as has been mentioned previously on the list) are in favor of this as well, and it is my understanding that other providers feel similarly. I would be in favor of any non-offensive name that we can reach consensus on. "trunk" sounds nice to me, but I think that it may cause problems for non-native English speakers, so perhaps "main" or "default" would suffice (maybe "main" is better, since it retains muscle memory for the first two characters without being offensive--at least, as far as I can tell. If I am wrong, please correct me and we should consider something else). All of that said, I can't emphasize enough how little I care about *what* name we replace "master" with, so long as it is (1) replaced with a non-offensive term, (2) that that change is done uniformly throughout the "Git Ecosystem" and (3) that the community can reach consensus on the new term in a respectful, appropriate, and considerate way. I only provided a few suggestions to get the conversation flowing, although I suspect that my help isn't needed there. > Don Goodman-Wilson (1): > init: allow overriding the default branch name for new repositories > > Johannes Schindelin (8): > remote: respect `core.defaultBranchName` > send-pack/transport-helper: respect `core.defaultBranchName` > testsvn: respect `core.defaultBranchName` > submodule: use the (possibly overridden) default branch name > clone: learn about the possibly-configured default branch name > fmt-merge-msg: learn about the possibly-configured default branch name > fast-export: respect the possibly-overridden default branch name > Document how the default branch name can be overridden > > Documentation/config/core.txt | 4 ++++ > builtin/clone.c | 14 +++++++++++--- > builtin/fast-export.c | 10 +++++++--- > builtin/init-db.c | 8 +++++--- > builtin/submodule--helper.c | 10 ++++++++-- > fmt-merge-msg.c | 6 ++++-- > refs.c | 34 ++++++++++++++++++++++++++++++++++ > refs.h | 6 ++++++ > remote-testsvn.c | 11 ++++++++--- > remote.c | 12 ++++++++---- > send-pack.c | 6 +++++- > t/README | 4 ++++ > t/t0001-init.sh | 20 ++++++++++++++++++++ > t/t5609-clone-branch.sh | 9 +++++++++ > t/t6200-fmt-merge-msg.sh | 8 ++++++++ > transport-helper.c | 6 +++++- > 16 files changed, 146 insertions(+), 22 deletions(-) > > > base-commit: 0313f36c6ebecb3bffe6f15cf25a4883100f0214 > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-656%2Fdscho%2Fdefault-branch-name-option-v1 > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-656/dscho/default-branch-name-option-v1 > Pull-Request: https://github.com/gitgitgadget/git/pull/656 > -- > gitgitgadget Thanks, Taylor
