Change non-inclusive naming

[dscho]

A thread on the Git mailing list made the cautious attempt at bringing this issue to attention: enough names in Git are non-inclusive to cause unintended consequences. Most prominently, the default name of the default branch.

I create this ticket to track the progress of fixing this.

While I want to fix it rather sooner than later, I want to abide by the saying "If you want to go fast, go alone, if you want to go far, go together". I want to go far on this.

Any constructive comments are welcome!

[UncannyBingo]

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)

[dscho]

@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".

[dscho]

@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

[dscho]

Got t1400 addressed.

[PhilipOakley]

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?

[dscho]

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.

[dscho]

@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.

[PhilipOakley]

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?

[dscho]

@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.

[UncannyBingo]

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 😄

[dscho]

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.

[PhilipOakley]

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?

[UncannyBingo]

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.

[derrickstolee]

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).

[UncannyBingo]

master is hard coded into git init.