Thanks for opening this issue! I've already started on some of the necessary work at https://github.com/DEGoodmanWilson/git but not all the unit tests are passing. Would love some help! (For reference: https://twitter.com/DEGoodmanWilson/status/1269931737515282438)

@DEGoodmanWilson thank you for your work!

Apart from the technical side, I think this will require a good deal of gentle communication on the Git mailing list, to convince especially the maintainer (but really, all the core contributors, on whose opinions the maintainer relies a fair bit) not only that this is something they will want to change, but also that they can change it.

I do have a slightly personal preference for the name default instead of trunk. As a non-native speaker, the former tells me without extra explanation what this branch is about, while I do not really understand why anybody (including Subversion folks) would call their default branch "trunk".

@DEGoodmanWilson I cherry-picked your change, changed the trunk to default (with a fixup in builtin/remote.c because default is a keyword in C and can therefore not be a variable name), and pushed it as inclusive-naming to https://github.com/dscho/git.

Note that we'll have to address the "whitelist/blacklist" issue, too.

So far, it seems that not too many tests are failing:

2020-06-08T11:16:44.4049719Z Test Summary Report
2020-06-08T11:16:44.4050241Z -------------------
2020-06-08T11:16:44.4050656Z t1400-update-ref.sh                              (Wstat: 256 Tests: 185 Failed: 5)
2020-06-08T11:16:44.4050930Z   Failed tests:  96, 105-107, 109
2020-06-08T11:16:44.4051185Z   Non-zero exit status: 1
2020-06-08T11:16:44.4051500Z t3205-branch-color.sh                            (Wstat: 256 Tests: 4 Failed: 1)
2020-06-08T11:16:44.4051622Z   Failed test:  4
2020-06-08T11:16:44.4051853Z   Non-zero exit status: 1
2020-06-08T11:16:44.4052192Z t3200-branch.sh                                  (Wstat: 256 Tests: 145 Failed: 4)
2020-06-08T11:16:44.4052466Z   Failed tests:  40-42, 44
2020-06-08T11:16:44.4052865Z   Non-zero exit status: 1
2020-06-08T11:16:44.4053109Z t3400-rebase.sh                                  (Wstat: 256 Tests: 35 Failed: 11)
2020-06-08T11:16:44.4053341Z   Failed tests:  19, 22-28, 32-34
2020-06-08T11:16:44.4053559Z   Non-zero exit status: 1
2020-06-08T11:16:44.4053815Z t3413-rebase-hook.sh                             (Wstat: 256 Tests: 15 Failed: 6)
2020-06-08T11:16:44.4054178Z   Failed tests:  5-10
2020-06-08T11:16:44.4054378Z   Non-zero exit status: 1
2020-06-08T11:16:44.4054629Z t4048-diff-combined-binary.sh                    (Wstat: 256 Tests: 14 Failed: 1)
2020-06-08T11:16:44.4054726Z   Failed test:  14
2020-06-08T11:16:44.4054909Z   Non-zero exit status: 1
2020-06-08T11:16:44.4055160Z t4013-diff-various.sh                            (Wstat: 256 Tests: 184 Failed: 73)
2020-06-08T11:16:44.4055411Z   Failed tests:  49-59, 62, 64-65, 67-87, 92-109, 113-116
2020-06-08T11:16:44.4055658Z                 124-127, 130-131, 133-136, 138-139, 157-159
2020-06-08T11:16:44.4055752Z                 162
2020-06-08T11:16:44.4055937Z   Non-zero exit status: 1
2020-06-08T11:16:44.4056186Z t4204-patch-id.sh                                (Wstat: 256 Tests: 16 Failed: 4)
2020-06-08T11:16:44.4056406Z   Failed tests:  3, 5-6, 14
2020-06-08T11:16:44.4056606Z   Non-zero exit status: 1
2020-06-08T11:16:44.4056840Z t5512-ls-remote.sh                               (Wstat: 256 Tests: 33 Failed: 1)
2020-06-08T11:16:44.4056934Z   Failed test:  28
2020-06-08T11:16:44.4057131Z   Non-zero exit status: 1
2020-06-08T11:16:44.4057379Z t5515-fetch-merge-logic.sh                       (Wstat: 256 Tests: 65 Failed: 64)
2020-06-08T11:16:44.4057573Z   Failed tests:  2-65
2020-06-08T11:16:44.4057773Z   Non-zero exit status: 1
2020-06-08T11:16:44.4058026Z t5548-push-porcelain.sh                          (Wstat: 256 Tests: 7 Failed: 1)
2020-06-08T11:16:44.4058298Z   Failed test:  2
2020-06-08T11:16:44.4058661Z   Non-zero exit status: 1
2020-06-08T11:16:44.4058932Z t5516-fetch-push.sh                              (Wstat: 256 Tests: 95 Failed: 1)
2020-06-08T11:16:44.4059033Z   Failed test:  86
2020-06-08T11:16:44.4059243Z   Non-zero exit status: 1
2020-06-08T11:16:44.4059678Z t5701-git-serve.sh                               (Wstat: 256 Tests: 13 Failed: 3)
2020-06-08T11:16:44.4059788Z   Failed tests:  7, 9, 11
2020-06-08T11:16:44.4060006Z   Non-zero exit status: 1
2020-06-08T11:16:44.4060279Z t6302-for-each-ref-filter.sh                     (Wstat: 256 Tests: 42 Failed: 17)
2020-06-08T11:16:44.4060492Z   Failed tests:  10-26
2020-06-08T11:16:44.4060709Z   Non-zero exit status: 1
2020-06-08T11:16:44.4060982Z t6300-for-each-ref.sh                            (Wstat: 256 Tests: 231 Failed: 1)
2020-06-08T11:16:44.4061083Z   Failed test:  230
2020-06-08T11:16:44.4061294Z   Non-zero exit status: 1
2020-06-08T11:16:44.4061550Z t7405-submodule-merge.sh                         (Wstat: 0 Tests: 18 Failed: 0)
2020-06-08T11:16:44.4062157Z   TODO passed:   17
2020-06-08T11:16:44.4062465Z t7608-merge-messages.sh                          (Wstat: 256 Tests: 5 Failed: 1)
2020-06-08T11:16:44.4062727Z   Failed test:  5
2020-06-08T11:16:44.4062909Z   Non-zero exit status: 1
2020-06-08T11:16:44.4063162Z t7400-submodule-basic.sh                         (Wstat: 256 Tests: 111 Failed: 1)
2020-06-08T11:16:44.4063351Z   Failed test:  20
2020-06-08T11:16:44.4063575Z   Non-zero exit status: 1
2020-06-08T11:16:44.4068191Z t9903-bash-prompt.sh                             (Wstat: 256 Tests: 66 Failed: 8)
2020-06-08T11:16:44.4068713Z   Failed tests:  47-48, 50-53, 55-56
2020-06-08T11:16:44.4069179Z   Non-zero exit status: 1
2020-06-08T11:16:44.4069625Z t9902-completion.sh                              (Wstat: 256 Tests: 152 Failed: 17)
2020-06-08T11:16:44.4070228Z   Failed tests:  38, 45-48, 79-81, 84, 123, 125, 129, 131-133
2020-06-08T11:16:44.4070450Z                 137, 139
2020-06-08T11:16:44.4070804Z   Non-zero exit status: 1

Got t1400 addressed.

I too was thinking about the issues raised in that post. I'd also thought "Do the 'origin' and 'master' names also cause problems because they are replicated so often?"

I'm thinking of the confusion say between upstream Git, and Git for Windows, both having a 'master' branch, so a user/dev following both will have difficulty if they try to have a 'master' branch that follows both. In that sense we should be advising everyone that having local 'master' branch is just as harmful as having too many 'goto's was in the past.

It took me a long while to realise that I should not even have a master branch, because I was not holding an authoritative copy of either Git or Git for Windows, rather I should always be starting new branches for working on issues from the respective git/master and gfw/master remote tracking branches. (this is lesson that takes a long time to learn for those of us who didn't grow up with Git 15 years ago).

I also try not to use origin as a repo name as I can never remember if, say, that's git or gfw (local short names).

I'm cautious about totally dropping the term 'master' because it does have its place when covering the idea of having mastery over a technique (e.g. those considered great painters). It should not be used as a method of denigration.

I am supportive helping users generate their own names for the upstream repository (rather than the dull, boring and uninformative origin), and that the initial checkout for a clone should be 'detached at' the upstream name, rather than being 'master'. We should use the distributed nature of git to promote diversity, rather than reinforce old misinformed habits.

Should Git for Windows have a 'master' branch, or should it be renamed? If so, to what?

I'm cautious about totally dropping the term 'master' because it does have its place when covering the idea of having mastery over a technique (e.g. those considered great painters). It should not be used as a method of denigration.

At this point, I don't think it matters what the intention behind the word is. It incites emotional distress. So we should move away from it.

Should Git for Windows have a 'master' branch, or should it be renamed? If so, to what?

I thought I had already answered at least the first question: yes, it will be renamed.

For the second question, I already put my vote in the hat: default.

@DEGoodmanWilson I force-pushed my branch with the fixes I came up with. It should pass the test suite now, although I still have to address a SHA-256 issue.

I'm cautious about totally dropping the term 'master' because it does have its place when covering the idea of having mastery over a technique (e.g. those considered great painters). It should not be used as a method of denigration.

At this point, I don't think it matters what the intention behind the word is. It incites emotional distress. So we should move away from it.

Having seen a number of cycles of these issues go by, we also need to look behind the issue at the processes and system, and change those as well. Banning words doesn't, of itself, solve the problem. We also need to address the things (process & system) that reinforce the misuse. That includes the little things within the git processes.

Should Git for Windows have a 'master' branch, or should it be renamed? If so, to what?

I thought I had already answered at least the first question: yes, it will be renamed.

For the second question, I already put my vote in the hat: default.

I had been thinking that reference might be an alternative for the typical authoritative repos that folk fork. But that highlights the problem that it's the process that is propagating the naming issue. If the primary Git for Windows branch is default, will it be recognised, and should git promulgate that name to all users who fork it. default doesn't feel authoritative (for Git for Windows). Though it does feel suitable for the 'as yet un-named' user's main branch. Maybe unnamed even?

@PhilipOakley I'm not aiming for perfect and complete. My aim is to get this started, with a reasonable name for starters. With that patch in hand, we can go to the Git mailing list and start some bike-shedding.

Having said that, I am pretty certain that default was one of the more obvious choices where Mercurial was just a lot smarter than Git.

I had actually started with "default", and was told it might be triggering for folks in financial trouble? I don't actually have an opinion myself.

As for "trunk"—that's the part of the tree that holds the branches 😄

I didn't think of that "default" meaning...

In any case, I think that the name needs to be decided on the Git mailing list (or in a virtual summit between the core Git contributors).

I'm willing to collect suggestions over here.

Hi @dscho, I'm happy with default (or un-named) as the default name for the unborn branch when a repo is initialised.

It's just that default doesn't feel like the correct name for the release(?!) branch in the Git for Windows repository (a different question to the git init branch naming). I believe that Git for Windows branch is always meant to be release ready, so could be also named that (release), though I had initially thought of reference. I'm sure there are other choices.

For the git init, IIUC, the template directory option has nothing to allow the initial branch to be named - it only provides initial content to the repo. (I've yet to check the proposed code to see which parts are adjusted at this stage)

However, that does create a difference in naming between the default branch name, and that of any upstream reference branch, made worse for users by the GitHub fork duplication process. I was mainly pointing out the naming issues at the cloning/forking/fetching level, and hence the implicit issues in users setting up their refspecs etc.

Does that help clarify anything?

One of the things I wanted to experiment with in my branch was not hard coding the default, but letting it be a configuration option. This might be a good stepping stone in an iterative approach, and also allow people to use the terms best suited for their communities. It’s more work of course, but hardly beyond our skills.

One of the things I wanted to experiment with in my branch was not hard coding the default, but letting it be a configuration option.

I actually went searching for this, but did not find anything in the docs. In addition, having a GIT_TEST_DEFAULT_BRANCH environment variable could allow us to identify the tests that need to be updated (and include a way to transition tests on a script-by-script basis).

master is hard coded into git init.

I believe that Git for Windows branch is always meant to be release ready, so could be also named that (release)

It is indeed meant to be release-ready at all times. However, actual releases are typically built from PR branches (most recently, refs/pull/2645/head). I therefore would fine release a bit misleading.

having a GIT_TEST_DEFAULT_BRANCH environment variable could allow us to identify the tests that need to be updated

That sounds like a good idea.

In practice, I found a couple tests that require reordering lines so that the branch names are ordered alphabetically, which will be made quite a bit harder if we allow for arbitrary default branch names to be configured.

master is hard coded into git init.

@DEGoodmanWilson yes, I think what @derrickstolee wanted to suggest is to introduce that environment variable, imitating other GIT_TEST_* environment variables meant to facilitate testing.

Having said that, given the complications with the practical aspects of implementing such a thing, I am unsure whether it is worth it, especially if the Git mailing list likely wants to pick a new, still hard-coded name.

In practice, I found a couple tests that require reordering lines so that the branch names are ordered alphabetically, which will be made quite a bit harder if we allow for arbitrary default branch names to be configured.

It's actually even worse: some tests verify output that is aligned, and changes with the name of the longest shown branch name...

I don't mean that the test suite should be resilient to any value of GIT_TEST_DEFAULT_BRANCH. What I mean is that we can update test scripts by setting GIT_TEST_DEFAULT_BRANCH=<new-default> at the beginning of a script, then change the expected output to match what the expected new behavior is. This can happen in small patches.

When the patches are done, then we can change the hard-coded value and delete the GIT_TEST_DEFAULT_BRANCH environment variable.

Step 1: Create GIT_TEST_DEFAULT_BRANCH.
Step 2: Update t000*.sh with GIT_TEST_DEFAULT_BRANCH=X
Step 3. Update t001*.sh with GIT_TEST_DEFAULT_BRANCH=X
...
Step N: Update t9*.sh with GIT_TEST_DEFAULT_BRANCH=X
Step N+1: Update default branch name
Step N + 2: Delete GIT_TEST_DEFAULT_BRANCH

@derrickstolee ah, that's a clever plan.

FWIW I managed to fix all remaining test failures in my inclusive-naming branch: https://github.com/dscho/git/actions/runs/129071782

Having said that, I now have second thoughts about using the name default, leaning more towards main. Thoughts?

Personal preference for main, but recognized it's just that; a personal preference, from my anecdotal history.

I was pointed to this StackOverflow answer that uses the templates to rename the default branch on the client side, by the way.

There is a lot of bike-shedding over what the default branch name should be. And existing projects have their own standards. I take this as a good reason to implement setting the default branch name as a config option, something I've been working on this morning. Nothing to share yet, because I'm still trying to understand how the git config system generates default values for un-configured options.

Then we can just use "main" or whatever, and let folks who want to use something else on future projects set a config option. The templatedir trick is a neat hack, but still far too complex for most folks I believe.

Personal preference for main, but recognized it's just that; a personal preference, from my anecdotal history.

Yes, even the thread on the Git mailing list I mentioned above suggests main. It does seem to be popular, so I think we should go with that.

My current plan is to solicit a bit more feedback on the Git and Git for Windows mailing lists, whether there are strong objections (with convincing reasons) against renaming to main, and then do that in Git for Windows' space.

I was pointed to this StackOverflow answer that uses the templates to rename the default branch on the client side, by the way.

Sure, that works, brian pointed that out in the reply to above-mentioned thread. It is a bit cumbersome, though, and it adds the confusing "re-initializing" message.

There is a lot of bike-shedding over what the default branch name should be.

Yes, there is. I do hope, though, that we can settle on a reasonable name in a reasonable time frame as far as Git for Windows is concerned, and then (re-)start the conversation on the Git mailing list to change the default within Git itself.

I take this as a good reason to implement setting the default branch name as a config option, something I've been working on this morning.

I guess you managed to convince me. The really neat part is that this ties nicely in with @derrickstolee's suggestion to adjust the test suite one by one. The config option and GIT_TEST_* setting can come first, then the tests are adjusted one by one, and in the end the default is flipped and all those GIT_TEST_* assignments in the test scripts go away. Then the documentation patches can follow.

Nothing to share yet, because I'm still trying to understand how the git config system generates default values for un-configured options.

@DEGoodmanWilson Oh, please do share a WIP, I am likely to be able to assist. FWIW I do hang out in https://gitter.im/git-for-windows/git if you want to chat.

FWIW I plan on tagging git/git@master...dscho:inclusive-naming (so that we have it for future reference) and then re-working it to rename the default branch to main instead.

Just to have something in hand when calling a Virtual Git Contributor Summit for Inclusive Naming.

Personal preference for main, but recognized it's just that; a personal preference, from my anecdotal history.

Yes, even the thread on the Git mailing list I mentioned above suggests main. It does seem to be popular, so I think we should go with that.

Seems that other thought leaders agree with this, e.g. https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx

@dscho I've got a working MVP here: https://github.com/DEGoodmanWilson/git/tree/default-branch-name-option

No tests, or docs, or checks that this doesn't break anything. Also, I am a little lost on the string pointer ownership conventions in git, so I know I've got a memory safety issue as well (which I've tagged with a comment, config.c:2376).

@dscho I've got a working MVP here: https://github.com/DEGoodmanWilson/git/tree/default-branch-name-option

@DEGoodmanWilson thanks for the MVP. I added some comments to the commit DEGoodmanWilson@d2a68b0. You will also need to update the commit message to be more in-line with Git community guidelines. See https://github.com/git-for-windows/git/blob/master/CONTRIBUTING.md#polish-your-commits for more information here.

@dscho I've got a working MVP here: https://github.com/DEGoodmanWilson/git/tree/default-branch-name-option

No tests, or docs, or checks that this doesn't break anything. Also, I am a little lost on the string pointer ownership conventions in git, so I know I've got a memory safety issue as well (which I've tagged with a comment, config.c:2376).

For the record, I talked @DEGoodmanWilson into opening a PR at gitgitgadget#653 and I commented liberally.

This is pretty exciting for me. I care deeply about helping Git become more inclusive, and I am delighted to see so much support.

For the record, I tagged yesterday's work of mine to rename the default branch name to default here: https://github.com/dscho/git/releases/tag/inclusive-naming-default (I intend to leave that tag there for eternity).

Now I'm off trying to edit the patches to use main instead.