Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tests: use main as default branch name #762

Closed
wants to merge 42 commits into from

Conversation

dscho
Copy link
Member

@dscho dscho commented Oct 16, 2020

This (big) patch series (almost) concludes the transition of Git's test suite to use init.defaultBranch=main that was started in js/default-branch-name-part-4-minus-1, continued in js/default-branch-name-adjust-t5411 and in js/default-branch-name-adjust-t5515. This transition prepares for changing the fall-back value of init.defaultBranch accordingly (which will be done in a different set of patch series, with an appropriate deprecation period), reflecting what many open source projects already did followed by GitHub, Azure Repos and others.

Before doing anything else, the series starts out with a patch that marks all the test scripts that expect a specific default branch name and won't pass with any other name.

Instead of one huge patch that reflects essentially a search-and-replace in the test suite, this patch series then splits the changes up into chunks that are intended to be smaller than 100kB so that they are not rejected by the Git mailing list. Interspersed between those changes are adjustments e.g. in alignment, to make it easier to review (or recreate) the search-and-replace patches.

Note that this branch is based on next, mostly because it would otherwise conflict with en/merge-tests, jk/diff-release-filespec-fix and ds/maintenance-part-3.

To avoid even more conflicts with topics that did not even make it to seen yet, this patch series specifically excludes t1309, t2106, t3040, t3404, t4013, t4015, t5310, t5526, t6300, t7064, t7817, t9902: in those test scripts, we will still use master for the time being. Once the topics in question have settled, I will send the appropriate follow-up patches to adjust them to use main instead.

Note that even after this patch series, master is still found in t/, even outside of the tests we excluded specifically to avoid conflicts with other patch series that are currently in flight: t/perf/, the git p4 tests (because git p4 still uses p4/master to refer to the remote main branch), and some comments still refer to this name. I intend to address at least some of those, in patch series separate from the current one.

Changes since v2:

  • The case statement setting the default branch name for each test script was replaced by an initial patch that sets the default branch name in those test scripts that need it (and only in those). This patch also modifies the linux-gcc job to verify that the test suite runs with overridden default branch name (which the now-marked test scripts over-override).
  • Four more test scripts were excluded from this patch series: t1309, t2106, t3040 and t4015. These are handled in four separate patch series, where I try to remove the requirement to hard-code the default branch name in the first place.

Changes since v1:

  • Dropped the commit changing the default initial branch name for git init.
  • Adjusted the patch for t1402 to also replace naster by nain.
  • Excluded t5526 from the patches for now, to avoid clashing with pk/subsub-fetch-fix.

cc: Felipe Contreras felipe.contreras@gmail.com
cc: Ævar Arnfjörð Bjarmason avarab@gmail.com
cc: Johannes Schindelin Johannes.Schindelin@gmx.de
cc: Jeff King peff@peff.net
cc: Jonathan Nieder jrnieder@gmail.com
cc: Philip Oakley philipoakley@iee.email
cc: Peter Hadlaw hadlawp@gmail.com
cc: Sergey Organov sorganov@gmail.com

@dscho dscho mentioned this pull request Oct 16, 2020
19 tasks
@gitgitgadget
Copy link

gitgitgadget bot commented Oct 16, 2020

The pull request has 40 commits. The max allowed is 30. Please split the patch series into multiple pull requests. Also consider squashing related commits.

@dscho dscho force-pushed the use-main-as-default-branch-name branch from 2da7fa2 to 8264d1d Compare November 11, 2020 20:31
@gitgitgadget
Copy link

gitgitgadget bot commented Nov 11, 2020

The pull request has 61 commits. The max allowed is 30. Please split the patch series into multiple pull requests. Also consider squashing related commits.

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 11, 2020

There are merge commits in this Pull Request:

2dbf2ce122ba765796004b8b460f91a716d478bc
e3ab0a0000b7788ffb4442433b17070358b1c99f
ee20cb60e81ce84f0d965af75126251a85717535
7b110c9c2f5c7b6c1ae2eaccbb0a8527429cba8d
f4c028a8e4d7a2334096a047728fc00e286a8623
2fd313246bab014b7ada7bc1453414c74f2988c2

Please rebase the branch and force-push.

@dscho dscho changed the base branch from master to next November 12, 2020 15:20
@dscho dscho force-pushed the use-main-as-default-branch-name branch from 8264d1d to c071acb Compare November 12, 2020 16:22
@gitgitgadget

This comment has been minimized.

@dscho dscho force-pushed the use-main-as-default-branch-name branch from c071acb to 00bc391 Compare November 12, 2020 19:13
@gitgitgadget

This comment has been minimized.

@dscho dscho force-pushed the use-main-as-default-branch-name branch from 00bc391 to 735b7ab Compare November 12, 2020 19:13
@dscho

This comment has been minimized.

@dscho dscho force-pushed the use-main-as-default-branch-name branch from 735b7ab to f853fa9 Compare November 12, 2020 21:29
@dscho
Copy link
Member Author

dscho commented Nov 12, 2020

/submit

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 12, 2020

Submitted as pull.762.git.1605221038.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git pr-762/dscho/use-main-as-default-branch-name-v1

To fetch this version to local tag pr-762/dscho/use-main-as-default-branch-name-v1:

git fetch --no-tags https://github.com/gitgitgadget/git tag pr-762/dscho/use-main-as-default-branch-name-v1

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 13, 2020

On the Git mailing list, Felipe Contreras wrote (reply to this):

On Thu, Nov 12, 2020 at 5:55 PM Johannes Schindelin via GitGitGadget
<gitgitgadget@gmail.com> wrote:

> This is the big one. This changes the default of init.defaultBranch to main,
> reflecting what many open source projects already did (which was followed by
> GitHub, Azure Repos and others).

I want to plant a big red flag here for the record.

I am against this change.

At the very least in the manner it is being made. I started a separate
thread [1] explaining the reasoning.

In addition to the manner--which I argue in that other thread should
be done for Git 3.0--I also object to the reasoning behind the change.

Let me know if you would rather hear my arguments against the
reasoning here, or in the other thread.

Cheers.

[1] https://lore.kernel.org/git/CAMP44s3BJ3dGsLJ-6yA-Po459=+m826KD9an4+P3qOY1vkbxZg@mail.gmail.com/

-- 
Felipe Contreras

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 13, 2020

User Felipe Contreras <felipe.contreras@gmail.com> has been added to the cc: list.

refs.c Outdated
@@ -575,7 +575,7 @@ char *repo_default_branch_name(struct repository *r)
die(_("could not retrieve `%s`"), config_display_key);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):


On Thu, Nov 12 2020, Don Goodman-Wilson via GitGitGadget wrote:

> The current default name for the initial branch is a loaded term, and
> many Open Source projects renamed their principal branches already. A
> common choice appears to be `main`.
>
> Let's follow their lead and change the default of `init.defaultBranch`.

I think it makes sense to split this change off from a 28-series test
cleanup series.

> diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh
> index bd3fa3c6da..1b0abcb0f8 100644
> --- a/t/lib-submodule-update.sh
> +++ b/t/lib-submodule-update.sh
> @@ -144,7 +144,7 @@ create_lib_submodule_repo () {
>  		git checkout -b valid_sub1 &&
>  		git revert HEAD &&
>  
> -		git checkout "${GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME-master}"
> +		git checkout "${GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME-main}"

Earlier in that function we're doing a "git init". With all this test
cleanup I wonder why not just "git rev-parse --abbrev-ref" to get the
default name, instead of carrying the hardcoding forward.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Johannes Schindelin wrote (reply to this):

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-169209211-1605276555=:18437
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi =C3=86var,

On Fri, 13 Nov 2020, =C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason wrote:

>
> On Thu, Nov 12 2020, Don Goodman-Wilson via GitGitGadget wrote:
>
> > The current default name for the initial branch is a loaded term, and
> > many Open Source projects renamed their principal branches already. A
> > common choice appears to be `main`.
> >
> > Let's follow their lead and change the default of `init.defaultBranch`=
.
>
> I think it makes sense to split this change off from a 28-series test
> cleanup series.

It is not a test cleanup. It is a series of 27 patches preparing the test
suite for the change made in the 28th patch.

I don't think that it is a good idea to split off that 28th patch from
the patches whose entire purpose is to prepare for that 28th patch.

>
> > diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh
> > index bd3fa3c6da..1b0abcb0f8 100644
> > --- a/t/lib-submodule-update.sh
> > +++ b/t/lib-submodule-update.sh
> > @@ -144,7 +144,7 @@ create_lib_submodule_repo () {
> >  		git checkout -b valid_sub1 &&
> >  		git revert HEAD &&
> >
> > -		git checkout "${GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME-master}"
> > +		git checkout "${GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME-main}"
>
> Earlier in that function we're doing a "git init". With all this test
> cleanup I wonder why not just "git rev-parse --abbrev-ref" to get the
> default name, instead of carrying the hardcoding forward.

My goal was to keep everything as close to its original as possible. In
v2.29.2, this line reads:

		git checkout master

See https://github.com/git/git/blob/v2.29.2/t/lib-submodule-update.sh#L147
to convince yourself.

Personally, I would have used something like

		main=3D$(git symbolic-ref --short HEAD) &&
		[...]
		git checkout $main

instead of what you suggested. That's a topic for another patch (series),
though.

Ciao,
Dscho

--8323328-169209211-1605276555=:18437--

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Junio C Hamano wrote (reply to this):

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi Ævar,
>
> On Fri, 13 Nov 2020, Ævar Arnfjörð Bjarmason wrote:
>
>>
>> On Thu, Nov 12 2020, Don Goodman-Wilson via GitGitGadget wrote:
>>
>> > The current default name for the initial branch is a loaded term, and
>> > many Open Source projects renamed their principal branches already. A
>> > common choice appears to be `main`.
>> >
>> > Let's follow their lead and change the default of `init.defaultBranch`.
>>
>> I think it makes sense to split this change off from a 28-series test
>> cleanup series.
>
> It is not a test cleanup. It is a series of 27 patches preparing the test
> suite for the change made in the 28th patch.
>
> I don't think that it is a good idea to split off that 28th patch from
> the patches whose entire purpose is to prepare for that 28th patch.

Well, I personally think that the "purpose" of the first 27 patches
must be updated if that is the case.  

The test should NOT be prepared only to work in the post "switch
from master to main" world.

Instead, what we want to see is that the test would work whether the
fallback default value for init.defaultBranch is 'master' (i.e. old
world) or 'main (i.e. a possible new world).  Perhaps by using the
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME mechanism for tests that relies
on a particular value to be the fallback default.  So in the sense,
the goal the first 26 patches support is the 27th one, which is the
most important one in the series from _my_ point of view.  We get
ourselves prepared so that 28th one can happen at any time.

That way, as long as the first 27 patches land, we will keep the
same test coverage as we've always had, regardless of the timing
we actually ship the 28th one to the production environment.

> Personally, I would have used something like
>
> 		main=$(git symbolic-ref --short HEAD) &&
> 		[...]
> 		git checkout $main
>
> instead of what you suggested. That's a topic for another patch (series),
> though.

Yeah, I would have used $primary or some word that is neither these
m* names, but I think that is a good alternative, when workable, to
the GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME mechanism.  When the golden
master compared with actual output hardcodes the expected branch
names, however, the approach becomes awkward, though.

Thanks.

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 13, 2020

User Ævar Arnfjörð Bjarmason <avarab@gmail.com> has been added to the cc: list.

@@ -48,11 +48,11 @@ test_expect_success 'pulling into void' '
test_cmp file cloned/file
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):


On Thu, Nov 12 2020, Johannes Schindelin via GitGitGadget wrote:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> This trick was performed via
>
> 	$ (cd t &&
> 	   sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \
> 		-e 's/Master/Main/g' -e 's/naster/nain/g' -- t55[23]*.sh)
>
> Note that t5533 contains a variation of the name `master` (`naster`)
> that we rename here, too.
>
> This commit allows us to define
> `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for that range of tests.

There's also a "naster" in t/t1402-check-ref-format.sh that's not
changed here and missed by 02/28 of this series.

Is there some meaning to the name "nain" and "naster" that I'm missing?
If not can we just call this "topic" or something while we're at it?
I.e. this on top (just s/nain/topic/g):

diff --git a/t/t5533-push-cas.sh b/t/t5533-push-cas.sh
index 9fcec604c3..4e33ec1fb9 100755
--- a/t/t5533-push-cas.sh
+++ b/t/t5533-push-cas.sh
@@ -201,12 +201,12 @@ test_expect_success 'cover everything with default force-with-lease (protected)'
 	setup_srcdst_basic &&
 	(
 		cd src &&
-		git branch nain main^
+		git branch topic main^
 	) &&
 	git ls-remote src refs/heads/\* >expect &&
 	(
 		cd dst &&
-		test_must_fail git push --force-with-lease origin main main:nain
+		test_must_fail git push --force-with-lease origin main main:topic
 	) &&
 	git ls-remote src refs/heads/\* >actual &&
 	test_cmp expect actual
@@ -216,16 +216,16 @@ test_expect_success 'cover everything with default force-with-lease (allowed)' '
 	setup_srcdst_basic &&
 	(
 		cd src &&
-		git branch nain main^
+		git branch topic main^
 	) &&
 	(
 		cd dst &&
 		git fetch &&
-		git push --force-with-lease origin main main:nain
+		git push --force-with-lease origin main main:topic
 	) &&
 	git ls-remote dst refs/heads/main |
-	sed -e "s/main/nain/" >expect &&
-	git ls-remote src refs/heads/nain >actual &&
+	sed -e "s/main/topic/" >expect &&
+	git ls-remote src refs/heads/topic >actual &&
 	test_cmp expect actual
 '
 

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Johannes Schindelin wrote (reply to this):

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-371731460-1605277095=:18437
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi =C3=86var,

On Fri, 13 Nov 2020, =C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason wrote:

>
> On Thu, Nov 12 2020, Johannes Schindelin via GitGitGadget wrote:
>
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > This trick was performed via
> >
> > 	$ (cd t &&
> > 	   sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \
> > 		-e 's/Master/Main/g' -e 's/naster/nain/g' -- t55[23]*.sh)
> >
> > Note that t5533 contains a variation of the name `master` (`naster`)
> > that we rename here, too.
> >
> > This commit allows us to define
> > `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=3Dmain` for that range of tests.
>
> There's also a "naster" in t/t1402-check-ref-format.sh that's not
> changed here and missed by 02/28 of this series.

Whoops, you're right. It's not even new: 7c3f847aad7 (check-ref-format
=2D-branch: do not expand @{...} outside repository, 2017-10-17) introduce=
d
it. I missed that one, thank you for pointing it out.

I will follow up with a separate patch to fix that, once the dust settles
on this here patch series.

> Is there some meaning to the name "nain" and "naster" that I'm missing?

I guess the original reasoning was to stay close to the original default
branch name. I'm not sure whether it is worth changing that idea. Like, if
you ask me whether it hurts to use "nain"? I looked up possible
connotations, and the most common one was "grandmother", and that's rather
endearing to me.

Ciao,
Dscho

> If not can we just call this "topic" or something while we're at it?
> I.e. this on top (just s/nain/topic/g):
>
> diff --git a/t/t5533-push-cas.sh b/t/t5533-push-cas.sh
> index 9fcec604c3..4e33ec1fb9 100755
> --- a/t/t5533-push-cas.sh
> +++ b/t/t5533-push-cas.sh
> @@ -201,12 +201,12 @@ test_expect_success 'cover everything with default=
 force-with-lease (protected)'
>  	setup_srcdst_basic &&
>  	(
>  		cd src &&
> -		git branch nain main^
> +		git branch topic main^
>  	) &&
>  	git ls-remote src refs/heads/\* >expect &&
>  	(
>  		cd dst &&
> -		test_must_fail git push --force-with-lease origin main main:nain
> +		test_must_fail git push --force-with-lease origin main main:topic
>  	) &&
>  	git ls-remote src refs/heads/\* >actual &&
>  	test_cmp expect actual
> @@ -216,16 +216,16 @@ test_expect_success 'cover everything with default=
 force-with-lease (allowed)' '
>  	setup_srcdst_basic &&
>  	(
>  		cd src &&
> -		git branch nain main^
> +		git branch topic main^
>  	) &&
>  	(
>  		cd dst &&
>  		git fetch &&
> -		git push --force-with-lease origin main main:nain
> +		git push --force-with-lease origin main main:topic
>  	) &&
>  	git ls-remote dst refs/heads/main |
> -	sed -e "s/main/nain/" >expect &&
> -	git ls-remote src refs/heads/nain >actual &&
> +	sed -e "s/main/topic/" >expect &&
> +	git ls-remote src refs/heads/topic >actual &&
>  	test_cmp expect actual
>  '
>
>

--8323328-371731460-1605277095=:18437--

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Junio C Hamano wrote (reply to this):

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Is there some meaning to the name "nain" and "naster" that I'm missing?

Not for "naster", which came from me who just chose "any single
letter" followed by "aster" to match 'master', and there is no other
reason.  I think Dscho just followed suit.

> If not can we just call this "topic" or something while we're at it?
> I.e. this on top (just s/nain/topic/g):
>
> diff --git a/t/t5533-push-cas.sh b/t/t5533-push-cas.sh
> index 9fcec604c3..4e33ec1fb9 100755
> --- a/t/t5533-push-cas.sh
> +++ b/t/t5533-push-cas.sh
> @@ -201,12 +201,12 @@ test_expect_success 'cover everything with default force-with-lease (protected)'
>  	setup_srcdst_basic &&
>  	(
>  		cd src &&
> -		git branch nain main^
> +		git branch topic main^
>  	) &&
>  	git ls-remote src refs/heads/\* >expect &&
>  	(
>  		cd dst &&
> -		test_must_fail git push --force-with-lease origin main main:nain
> +		test_must_fail git push --force-with-lease origin main main:topic
>  	) &&
>  	git ls-remote src refs/heads/\* >actual &&
>  	test_cmp expect actual
> @@ -216,16 +216,16 @@ test_expect_success 'cover everything with default force-with-lease (allowed)' '
>  	setup_srcdst_basic &&
>  	(
>  		cd src &&
> -		git branch nain main^
> +		git branch topic main^
>  	) &&
>  	(
>  		cd dst &&
>  		git fetch &&
> -		git push --force-with-lease origin main main:nain
> +		git push --force-with-lease origin main main:topic
>  	) &&
>  	git ls-remote dst refs/heads/main |
> -	sed -e "s/main/nain/" >expect &&
> -	git ls-remote src refs/heads/nain >actual &&
> +	sed -e "s/main/topic/" >expect &&
> +	git ls-remote src refs/heads/topic >actual &&
>  	test_cmp expect actual
>  '
>  

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 13, 2020

On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):


On Thu, Nov 12 2020, Johannes Schindelin via GitGitGadget wrote:

> This is the big one. This changes the default of init.defaultBranch to main,
> reflecting what many open source projects already did (which was followed by
> GitHub, Azure Repos and others).

I don't have an issue with the end goal of s/master/main|$whatever/ as
UX here as noted in previous related review rounds. But I don't think
this series as it stands is anywhere near ready.

This is 27 patches of s/master/main/ in the tests, followed by making
the change to the default in refs.c without as much as a single
documentation update to inform users of the change.

I don't see the point in doing these sorts of test suite changes, it
just seems like needless churn. But I have not read the whole backlog of
previous iterations of this & related patches, so bear with me.

Why not instead do what we did when we added protocol v2 to the tests,
e.g. in 8a1b0978ab ("test: request GIT_TEST_PROTOCOL_VERSION=0 when
appropriate", 2019-12-23) we simply set the t5515 test to always run
with protocol v1. If you'd do this:
    
    diff --git a/t/t5515-fetch-merge-logic.sh b/t/t5515-fetch-merge-logic.sh
    index 70a9d2d8ab..939c8b2f83 100755
    --- a/t/t5515-fetch-merge-logic.sh
    +++ b/t/t5515-fetch-merge-logic.sh
    @@ -11,6 +11,9 @@ test_description='Merge logic in fetch'
     GIT_TEST_PROTOCOL_VERSION=0
     export GIT_TEST_PROTOCOL_VERSION
     
    +GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master
    +export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
    +
     . ./test-lib.sh
     
     build_script () {
    
Of course that also needs:
    
    index fa347ed3e1..2d700a171b 100644
    --- a/t/test-lib.sh
    +++ b/t/test-lib.sh
    @@ -1711,10 +1711,8 @@ test_lazy_prereq SHA1 '
     test_lazy_prereq REBASE_P '
     	test -z "$GIT_TEST_SKIP_REBASE_P"
     '
    -# Special-purpose prereq for transitioning to a new default branch name:
    -# Some tests need more than just a mindless (case-preserving) s/master/main/g
    -# replacement. The non-trivial adjustments are guarded behind this
    -# prerequisite, acting kind of as a feature flag
    -test_lazy_prereq PREPARE_FOR_MAIN_BRANCH '
    -	test "$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME" = main
    +
    +test_lazy_prereq MAIN_BRANCH_IS_MASTER '
    +	test -z "$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME" ||
    +	test "$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME" = "master"
     '

Because (but see "later" a few paragraphs later), the logic as it stands
on "master" is entirely backwards & broken. I.e. if you don't set
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME or set it to "master" we now skip a
bunch of tests ... which only work if the value is "master". If you set
it to "main" they'll break.

Then instead of ending up with a hardcoding of "main" we'd be able to
run the tests with a new custom branch name (even one with whitespace in
it). That coverage is plenty to test any branch name hardcoding.

The remaining tests that would still have "master" would then just be
dealt with by the same thing we did for the too-protocol-v1-specific
tests, i.e.:
    
    diff --git a/t/t3502-cherry-pick-merge.sh b/t/t3502-cherry-pick-merge.sh
    index 8b635a196d..354f9bd851 100755
    --- a/t/t3502-cherry-pick-merge.sh
    +++ b/t/t3502-cherry-pick-merge.sh
    @@ -8,6 +8,8 @@ test_description='cherry picking and reverting a merge
     
     '
     
    +GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master
    +export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
     . ./test-lib.sh
     
     test_expect_success setup '
    
Except unlike protocol v1/v2 we're really not gaining anything in
coverage by going further, it's not the point of any of these tests to
test for the default branch name. It's a *lot* of churn, 

"Later": After writing the above I see from 704fed9ea2 ("tests: start
moving to a different default main branch name", 2020-10-23) that this
state of affairs is intentional. But doesn't discuss why the more usual
(because we've done it that way a few times before) v1/v2-esque
transition wasn't done instead.

Doing it the other way still seems better. We're now not running our
full tests in anticipation for this series landing on "master", and
after applying this we're still not running all of them.

Anyway, enough with discussing this detail of the test suite churn. My
main objection to this version of it is:

After this series as it stands lands what's a rather big UI change in
git isn't discussed *anywhere* in the docs.

I'm not saying we need some similar s/master/main/g in Documentation/ as
what's being done here in t/, but I think a bare minimum for a rather
big UI change like this is:

 1) Let's at least talk about it in some way in git-init(1), i.e. that
    it used to be "master" before version so-and-so and is now
    different. With this series applied we still say:

    Documentation/git-init.txt:If not specified, fall back to the default name: `master`.

 2) Ditto in the init.defaultBranch and things like that

 3) After all this effort at eliminating "master" entirely in the tests
    we're still shipping a sample hook that expects "master" on "git
    init", and breaks now that it's "main"

And maybe stuff like:

 4) Have "git init" emit some new advice message saying that the default
    has changed and we've init-ed a new repo with a "main" branch.

Our primary concern should be the vast majority of users who don't
follow this topic on Twitter, don't read this mailing list, and are just
going to waste 10 minutes of their day because some script they've had
working for years using "git init" did something unexpected.

Let's at least aim to make that 5 minutes instead by making the change
more discoverable.

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 13, 2020

User Johannes Schindelin <Johannes.Schindelin@gmx.de> has been added to the cc: list.

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 13, 2020

On the Git mailing list, Johannes Schindelin wrote (reply to this):

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-379568793-1605277349=:18437
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi =C3=86var,

On Fri, 13 Nov 2020, =C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason wrote:

> On Thu, Nov 12 2020, Johannes Schindelin via GitGitGadget wrote:
>
> > This is the big one. This changes the default of init.defaultBranch to=
 main,
> > reflecting what many open source projects already did (which was follo=
wed by
> > GitHub, Azure Repos and others).
>
> I don't have an issue with the end goal of s/master/main|$whatever/ as
> UX here as noted in previous related review rounds. But I don't think
> this series as it stands is anywhere near ready.
>
> This is 27 patches of s/master/main/ in the tests, followed by making
> the change to the default in refs.c without as much as a single
> documentation update to inform users of the change.

Of course, this is _the one_ patch series mentioned in
https://github.com/gitgitgadget/git/pull/655 that does _not_ link back to
the meta-PR.

So you're right, on its own, these 28 patches do not make sense.

And if you split off the 28th patch, the remaining 27 patches make even
less sense.

The reason why I partitioned the changes this way was that it is a _ton_
of patches to review, and in many ways, these 28 patches are the most
important ones to review (I didn't want to just rely on the CI builds
passing, I reviewed those patches carefully, multiple times, to make sure
that they made sense in the goal to transition to `main`).

I will respond to the rest of your concerns later,
Dscho

>
> I don't see the point in doing these sorts of test suite changes, it
> just seems like needless churn. But I have not read the whole backlog of
> previous iterations of this & related patches, so bear with me.
>
> Why not instead do what we did when we added protocol v2 to the tests,
> e.g. in 8a1b0978ab ("test: request GIT_TEST_PROTOCOL_VERSION=3D0 when
> appropriate", 2019-12-23) we simply set the t5515 test to always run
> with protocol v1. If you'd do this:
>
>     diff --git a/t/t5515-fetch-merge-logic.sh b/t/t5515-fetch-merge-logi=
c.sh
>     index 70a9d2d8ab..939c8b2f83 100755
>     --- a/t/t5515-fetch-merge-logic.sh
>     +++ b/t/t5515-fetch-merge-logic.sh
>     @@ -11,6 +11,9 @@ test_description=3D'Merge logic in fetch'
>      GIT_TEST_PROTOCOL_VERSION=3D0
>      export GIT_TEST_PROTOCOL_VERSION
>
>     +GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=3Dmaster
>     +export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
>     +
>      . ./test-lib.sh
>
>      build_script () {
>
> Of course that also needs:
>
>     index fa347ed3e1..2d700a171b 100644
>     --- a/t/test-lib.sh
>     +++ b/t/test-lib.sh
>     @@ -1711,10 +1711,8 @@ test_lazy_prereq SHA1 '
>      test_lazy_prereq REBASE_P '
>      	test -z "$GIT_TEST_SKIP_REBASE_P"
>      '
>     -# Special-purpose prereq for transitioning to a new default branch =
name:
>     -# Some tests need more than just a mindless (case-preserving) s/mas=
ter/main/g
>     -# replacement. The non-trivial adjustments are guarded behind this
>     -# prerequisite, acting kind of as a feature flag
>     -test_lazy_prereq PREPARE_FOR_MAIN_BRANCH '
>     -	test "$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME" =3D main
>     +
>     +test_lazy_prereq MAIN_BRANCH_IS_MASTER '
>     +	test -z "$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME" ||
>     +	test "$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME" =3D "master"
>      '
>
> Because (but see "later" a few paragraphs later), the logic as it stands
> on "master" is entirely backwards & broken. I.e. if you don't set
> GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME or set it to "master" we now skip a
> bunch of tests ... which only work if the value is "master". If you set
> it to "main" they'll break.
>
> Then instead of ending up with a hardcoding of "main" we'd be able to
> run the tests with a new custom branch name (even one with whitespace in
> it). That coverage is plenty to test any branch name hardcoding.
>
> The remaining tests that would still have "master" would then just be
> dealt with by the same thing we did for the too-protocol-v1-specific
> tests, i.e.:
>
>     diff --git a/t/t3502-cherry-pick-merge.sh b/t/t3502-cherry-pick-merg=
e.sh
>     index 8b635a196d..354f9bd851 100755
>     --- a/t/t3502-cherry-pick-merge.sh
>     +++ b/t/t3502-cherry-pick-merge.sh
>     @@ -8,6 +8,8 @@ test_description=3D'cherry picking and reverting a m=
erge
>
>      '
>
>     +GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=3Dmaster
>     +export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
>      . ./test-lib.sh
>
>      test_expect_success setup '
>
> Except unlike protocol v1/v2 we're really not gaining anything in
> coverage by going further, it's not the point of any of these tests to
> test for the default branch name. It's a *lot* of churn,
>
> "Later": After writing the above I see from 704fed9ea2 ("tests: start
> moving to a different default main branch name", 2020-10-23) that this
> state of affairs is intentional. But doesn't discuss why the more usual
> (because we've done it that way a few times before) v1/v2-esque
> transition wasn't done instead.
>
> Doing it the other way still seems better. We're now not running our
> full tests in anticipation for this series landing on "master", and
> after applying this we're still not running all of them.
>
> Anyway, enough with discussing this detail of the test suite churn. My
> main objection to this version of it is:
>
> After this series as it stands lands what's a rather big UI change in
> git isn't discussed *anywhere* in the docs.
>
> I'm not saying we need some similar s/master/main/g in Documentation/ as
> what's being done here in t/, but I think a bare minimum for a rather
> big UI change like this is:
>
>  1) Let's at least talk about it in some way in git-init(1), i.e. that
>     it used to be "master" before version so-and-so and is now
>     different. With this series applied we still say:
>
>     Documentation/git-init.txt:If not specified, fall back to the defaul=
t name: `master`.
>
>  2) Ditto in the init.defaultBranch and things like that
>
>  3) After all this effort at eliminating "master" entirely in the tests
>     we're still shipping a sample hook that expects "master" on "git
>     init", and breaks now that it's "main"
>
> And maybe stuff like:
>
>  4) Have "git init" emit some new advice message saying that the default
>     has changed and we've init-ed a new repo with a "main" branch.
>
> Our primary concern should be the vast majority of users who don't
> follow this topic on Twitter, don't read this mailing list, and are just
> going to waste 10 minutes of their day because some script they've had
> working for years using "git init" did something unexpected.
>
> Let's at least aim to make that 5 minutes instead by making the change
> more discoverable.
>

--8323328-379568793-1605277349=:18437--

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 13, 2020

On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):

Since 704fed9ea2 ("tests: start moving to a different default main
branch name", 2020-10-23) we've been needlessly skipping tests if the
branch is "master" in preparation for an eventual switch to another name.

As I noted in [1] I don't see why we shouldn't be doing a more
graceful approach here where we don't start skipping unrelated tests
just because some s/master/main/g changes are in flight.

Furthermore the seeming goal of eliminating the string "master" from
anywhere in git's sources results in needless patch churn, and has
nothing to do with the goal of changing the branch name in the UX.

This patch demonstrates that things could be much simpler if we don't
set ourselves that requirement. Now we:

 * Can set GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=<some-name>, but this
   no longer overrides config, so it behaves like other GIT_TEST_*
   variables.

 * Have a test-tool helper that gives us refs.c's idea of the main
   branch name to share the logic between the tests and the main C
   code.

 * A lot of tests (but a small minority of the total) have master
   "master" hardcoded in some way. We now inventory them in
   tests-that-need-master.txt, we can still remove the names from that
   file and manually change the code later, but this accomplishes a
   clean test run with a relatively easy-to-review diff.

   We ignore GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=<name> when it comes
   to these files, unless
   GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME_HARDER=true is set.

 * The changes to t5515-fetch-merge-logic.sh and
   t5560-http-backend-noserver.sh show how much easier it is to just
   punt on certain tests. In these tests that heavily rely on the
   "master" name (not inherently, it's just hardcoded in a lot of
   places) we just give up and keep using "master".

1. https://lore.kernel.org/git/87pn4hfmc4.fsf@evledraar.gmail.com/

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---

I need to walk away from the computer now, but this is an RFC of what
I was commenting on upthread.

 Makefile                            |   1 +
 config.c                            |  10 +
 config.h                            |   1 +
 refs.c                              |   7 +-
 t/helper/test-default-branch-name.c |  16 ++
 t/helper/test-tool.c                |   1 +
 t/helper/test-tool.h                |   1 +
 t/t0001-init.sh                     |   2 +-
 t/t5515-fetch-merge-logic.sh        |   3 +
 t/t5560-http-backend-noserver.sh    |   4 +
 t/test-lib.sh                       |  27 ++-
 t/tests-that-need-master.txt        | 343 ++++++++++++++++++++++++++++
 12 files changed, 403 insertions(+), 13 deletions(-)
 create mode 100644 t/helper/test-default-branch-name.c
 create mode 100644 t/tests-that-need-master.txt

diff --git a/Makefile b/Makefile
index 790a883932..fb94c836e2 100644
--- a/Makefile
+++ b/Makefile
@@ -696,6 +696,7 @@ TEST_BUILTINS_OBJS += test-chmtime.o
 TEST_BUILTINS_OBJS += test-config.o
 TEST_BUILTINS_OBJS += test-ctype.o
 TEST_BUILTINS_OBJS += test-date.o
+TEST_BUILTINS_OBJS += test-default-branch-name.o
 TEST_BUILTINS_OBJS += test-delta.o
 TEST_BUILTINS_OBJS += test-dir-iterator.o
 TEST_BUILTINS_OBJS += test-drop-caches.o
diff --git a/config.c b/config.c
index 2bdff4457b..0c12864b79 100644
--- a/config.c
+++ b/config.c
@@ -1706,6 +1706,16 @@ unsigned long git_env_ulong(const char *k, unsigned long val)
 	return val;
 }
 
+/*
+ * Parse environment variable 'k' as a char *; if missing, use the
+ * default value 'def'.
+ */
+const char* git_env_str(const char *k, const char *def)
+{
+	const char *v = getenv(k);
+	return v && strlen(v) ? v : def;
+}
+
 int git_config_system(void)
 {
 	return !git_env_bool("GIT_CONFIG_NOSYSTEM", 0);
diff --git a/config.h b/config.h
index 91cdfbfb41..36a7284f8a 100644
--- a/config.h
+++ b/config.h
@@ -298,6 +298,7 @@ int git_config_copy_section_in_file(const char *, const char *, const char *);
 const char *git_etc_gitconfig(void);
 int git_env_bool(const char *, int);
 unsigned long git_env_ulong(const char *, unsigned long);
+const char* git_env_str(const char *, const char *);
 int git_config_system(void);
 int config_error_nonbool(const char *);
 #if defined(__GNUC__)
diff --git a/refs.c b/refs.c
index 392f0bbf68..ca8875e945 100644
--- a/refs.c
+++ b/refs.c
@@ -567,15 +567,12 @@ char *repo_default_branch_name(struct repository *r)
 	const char *config_key = "init.defaultbranch";
 	const char *config_display_key = "init.defaultBranch";
 	char *ret = NULL, *full_ref;
-	const char *env = getenv("GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME");
 
-	if (env && *env)
-		ret = xstrdup(env);
-	else if (repo_config_get_string(r, config_key, &ret) < 0)
+	if (repo_config_get_string(r, config_key, &ret) < 0)
 		die(_("could not retrieve `%s`"), config_display_key);
 
 	if (!ret)
-		ret = xstrdup("master");
+		ret = xstrdup(git_env_str("GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME", "master"));
 
 	full_ref = xstrfmt("refs/heads/%s", ret);
 	if (check_refname_format(full_ref, 0))
diff --git a/t/helper/test-default-branch-name.c b/t/helper/test-default-branch-name.c
new file mode 100644
index 0000000000..1a0c8502ee
--- /dev/null
+++ b/t/helper/test-default-branch-name.c
@@ -0,0 +1,16 @@
+#include "test-tool.h"
+#include "git-compat-util.h"
+#include "refs.h"
+
+/*
+ * usage:
+ * tool-test default-branch-name
+ */
+int cmd__default_branch_name(int argc, const char **argv)
+{
+	const char *name = git_default_branch_name();
+
+	puts(name);
+
+	return 0;
+}
diff --git a/t/helper/test-tool.c b/t/helper/test-tool.c
index a0d3966b29..ad4bd7274c 100644
--- a/t/helper/test-tool.c
+++ b/t/helper/test-tool.c
@@ -21,6 +21,7 @@ static struct test_cmd cmds[] = {
 	{ "ctype", cmd__ctype },
 	{ "date", cmd__date },
 	{ "delta", cmd__delta },
+	{ "default-branch-name", cmd__default_branch_name },
 	{ "dir-iterator", cmd__dir_iterator },
 	{ "drop-caches", cmd__drop_caches },
 	{ "dump-cache-tree", cmd__dump_cache_tree },
diff --git a/t/helper/test-tool.h b/t/helper/test-tool.h
index 07034d3f38..e0dda6bfd8 100644
--- a/t/helper/test-tool.h
+++ b/t/helper/test-tool.h
@@ -10,6 +10,7 @@ int cmd__chmtime(int argc, const char **argv);
 int cmd__config(int argc, const char **argv);
 int cmd__ctype(int argc, const char **argv);
 int cmd__date(int argc, const char **argv);
+int cmd__default_branch_name(int argc, const char **argv);
 int cmd__delta(int argc, const char **argv);
 int cmd__dir_iterator(int argc, const char **argv);
 int cmd__drop_caches(int argc, const char **argv);
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 69a320489f..68adb9a832 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -562,7 +562,7 @@ test_expect_success 'overridden default main branch name (env)' '
 	test_config_global init.defaultBranch nmb &&
 	GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=env git init main-branch-env &&
 	git -C main-branch-env symbolic-ref HEAD >actual &&
-	grep env actual
+	grep nmb actual
 '
 
 test_expect_success 'invalid default branch name' '
diff --git a/t/t5515-fetch-merge-logic.sh b/t/t5515-fetch-merge-logic.sh
index 70a9d2d8ab..939c8b2f83 100755
--- a/t/t5515-fetch-merge-logic.sh
+++ b/t/t5515-fetch-merge-logic.sh
@@ -11,6 +11,9 @@ test_description='Merge logic in fetch'
 GIT_TEST_PROTOCOL_VERSION=0
 export GIT_TEST_PROTOCOL_VERSION
 
+GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master
+export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
+
 . ./test-lib.sh
 
 build_script () {
diff --git a/t/t5560-http-backend-noserver.sh b/t/t5560-http-backend-noserver.sh
index 9fafcf1945..27b31745ad 100755
--- a/t/t5560-http-backend-noserver.sh
+++ b/t/t5560-http-backend-noserver.sh
@@ -1,6 +1,10 @@
 #!/bin/sh
 
 test_description='test git-http-backend-noserver'
+
+GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master
+export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
+
 . ./test-lib.sh
 
 HTTPD_DOCUMENT_ROOT_PATH="$TRASH_DIRECTORY"
diff --git a/t/test-lib.sh b/t/test-lib.sh
index fa347ed3e1..11ea009717 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1382,6 +1382,26 @@ HOME="$TRASH_DIRECTORY"
 GNUPGHOME="$HOME/gnupg-home-not-used"
 export HOME GNUPGHOME
 
+# Check if we're doing tests with the main branch != master, and if
+# we'd like to override that for known-broken tests.
+GIT_TEST_MAIN=$(test-tool default-branch-name)
+if test "$GIT_TEST_MAIN" = "master"
+then
+	test_set_prereq MAIN_BRANCH_IS_MASTER
+else
+	if test -z "$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME_HARDER" &&
+	   grep -q $TEST_NAME "$TEST_DIRECTORY/tests-that-need-master.txt"
+	then
+		echo overriding
+		GIT_TEST_MAIN=master
+		GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master
+		test_set_prereq MAIN_BRANCH_IS_MASTER
+	fi
+fi
+export GIT_TEST_MAIN
+export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
+
+# Initialize the repository after we know the main branch name.
 if test -z "$TEST_NO_CREATE_REPO"
 then
 	test_create_repo "$TRASH_DIRECTORY"
@@ -1711,10 +1731,3 @@ test_lazy_prereq SHA1 '
 test_lazy_prereq REBASE_P '
 	test -z "$GIT_TEST_SKIP_REBASE_P"
 '
-# Special-purpose prereq for transitioning to a new default branch name:
-# Some tests need more than just a mindless (case-preserving) s/master/main/g
-# replacement. The non-trivial adjustments are guarded behind this
-# prerequisite, acting kind of as a feature flag
-test_lazy_prereq PREPARE_FOR_MAIN_BRANCH '
-	test "$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME" = main
-'
diff --git a/t/tests-that-need-master.txt b/t/tests-that-need-master.txt
new file mode 100644
index 0000000000..d7a693b19e
--- /dev/null
+++ b/t/tests-that-need-master.txt
@@ -0,0 +1,343 @@
+t0002-gitfile.sh
+t0020-crlf.sh
+t0021-conversion.sh
+t0027-auto-crlf.sh
+t0028-working-tree-encoding.sh
+t0041-usage.sh
+t0050-filesystem.sh
+t0060-path-utils.sh
+t0100-previous.sh
+t1004-read-tree-m-u-wf.sh
+t1008-read-tree-overlay.sh
+t1009-read-tree-new-index.sh
+t1011-read-tree-sparse-checkout.sh
+t1021-rerere-in-workdir.sh
+t1090-sparse-checkout-scope.sh
+t1091-sparse-checkout-builtin.sh
+t1300-config.sh
+t1301-shared-repo.sh
+t1305-config-include.sh
+t1309-early-config.sh
+t1400-update-ref.sh
+t1402-check-ref-format.sh
+t1403-show-ref.sh
+t1405-main-ref-store.sh
+t1406-submodule-ref-store.sh
+t1407-worktree-ref-store.sh
+t1408-packed-refs.sh
+t1410-reflog.sh
+t1411-reflog-show.sh
+t1413-reflog-detach.sh
+t1414-reflog-walk.sh
+t1416-ref-transaction-hooks.sh
+t1430-bad-ref-name.sh
+t1450-fsck.sh
+t1500-rev-parse.sh
+t1503-rev-parse-verify.sh
+t1505-rev-parse-last.sh
+t1506-rev-parse-diagnosis.sh
+t1507-rev-parse-upstream.sh
+t1508-at-combinations.sh
+t1511-rev-parse-caret.sh
+t1512-rev-parse-disambiguation.sh
+t1513-rev-parse-prefix.sh
+t1514-rev-parse-push.sh
+t1700-split-index.sh
+t2007-checkout-symlink.sh
+t2009-checkout-statinfo.sh
+t2010-checkout-ambiguous.sh
+t2011-checkout-invalid-head.sh
+t2012-checkout-last.sh
+t2015-checkout-unborn.sh
+t2017-checkout-orphan.sh
+t2020-checkout-detach.sh
+t2022-checkout-paths.sh
+t2023-checkout-m.sh
+t2024-checkout-dwim.sh
+t2027-checkout-track.sh
+t2030-unresolve-info.sh
+t2060-switch.sh
+t2070-restore.sh
+t2106-update-index-assume-unchanged.sh
+t2400-worktree-add.sh
+t2401-worktree-prune.sh
+t2402-worktree-list.sh
+t2405-worktree-submodule.sh
+t3040-subprojects-basic.sh
+t3200-branch.sh
+t3201-branch-contains.sh
+t3202-show-branch-octopus.sh
+t3203-branch-output.sh
+t3204-branch-name-interpretation.sh
+t3205-branch-color.sh
+t3206-range-diff.sh
+t3210-pack-refs.sh
+t3211-peel-ref.sh
+t3301-notes.sh
+t3302-notes-index-expensive.sh
+t3303-notes-subtrees.sh
+t3304-notes-mixed.sh
+t3308-notes-merge.sh
+t3320-notes-merge-worktrees.sh
+t3400-rebase.sh
+t3402-rebase-merge.sh
+t3403-rebase-skip.sh
+t3405-rebase-malformed.sh
+t3406-rebase-message.sh
+t3407-rebase-abort.sh
+t3408-rebase-multi-line.sh
+t3409-rebase-preserve-merges.sh
+t3412-rebase-root.sh
+t3413-rebase-hook.sh
+t3415-rebase-autosquash.sh
+t3416-rebase-onto-threedots.sh
+t3418-rebase-continue.sh
+t3419-rebase-patch-id.sh
+t3420-rebase-autostash.sh
+t3423-rebase-reword.sh
+t3427-rebase-subtree.sh
+t3430-rebase-merges.sh
+t3431-rebase-fork-point.sh
+t3432-rebase-fast-forward.sh
+t3434-rebase-i18n.sh
+t3435-rebase-gpg-sign.sh
+t3436-rebase-more-options.sh
+t3500-cherry.sh
+t3501-revert-cherry-pick.sh
+t3502-cherry-pick-merge.sh
+t3503-cherry-pick-root.sh
+t3504-cherry-pick-rerere.sh
+t3505-cherry-pick-empty.sh
+t3506-cherry-pick-ff.sh
+t3507-cherry-pick-conflict.sh
+t3508-cherry-pick-many-commits.sh
+t3509-cherry-pick-merge-df.sh
+t3512-cherry-pick-submodule.sh
+t3600-rm.sh
+t3701-add-interactive.sh
+t3901-i18n-patch.sh
+t3903-stash.sh
+t3910-mac-os-precompose.sh
+t4014-format-patch.sh
+t4015-diff-whitespace.sh
+t4017-diff-retval.sh
+t4038-diff-combined.sh
+t4041-diff-submodule-option.sh
+t4048-diff-combined-binary.sh
+t4052-stat-output.sh
+t4056-diff-order.sh
+t4057-diff-combined-paths.sh
+t4061-diff-indent.sh
+t4066-diff-emit-delay.sh
+t4068-diff-symmetric-merge-base.sh
+t4103-apply-binary.sh
+t4108-apply-threeway.sh
+t4121-apply-diffs.sh
+t4122-apply-symlink-inside.sh
+t4150-am.sh
+t4200-rerere.sh
+t4201-shortlog.sh
+t4202-log.sh
+t4203-mailmap.sh
+t4204-patch-id.sh
+t4207-log-decoration-colors.sh
+t4208-log-magic-pathspec.sh
+t4214-log-graph-octopus.sh
+t4216-log-bloom.sh
+t4253-am-keep-cr-dos.sh
+t4257-am-interactive.sh
+t5150-request-pull.sh
+t5304-prune.sh
+t5305-include-tag.sh
+t5312-prune-corruption.sh
+t5317-pack-objects-filter-objects.sh
+t5322-pack-objects-sparse.sh
+t5323-pack-redundant.sh
+t5400-send-pack.sh
+t5401-update-hooks.sh
+t5402-post-merge-hook.sh
+t5403-post-checkout-hook.sh
+t5404-tracking-branches.sh
+t5405-send-pack-rewind.sh
+t5407-post-rewrite-hook.sh
+t5410-receive-pack-alternates.sh
+t5500-fetch-pack.sh
+t5501-fetch-push-alternates.sh
+t5502-quickfetch.sh
+t5503-tagfollow.sh
+t5504-fetch-receive-strict.sh
+t5505-remote.sh
+t5506-remote-groups.sh
+t5509-fetch-push-namespaces.sh
+t5510-fetch.sh
+t5511-refspec.sh
+t5512-ls-remote.sh
+t5514-fetch-multiple.sh
+t5516-fetch-push.sh
+t5517-push-mirror.sh
+t5518-fetch-exit-status.sh
+t5519-push-alternates.sh
+t5520-pull.sh
+t5521-pull-options.sh
+t5523-push-upstream.sh
+t5526-fetch-submodules.sh
+t5527-fetch-odd-refs.sh
+t5528-push-default.sh
+t5529-push-errors.sh
+t5530-upload-pack-error.sh
+t5531-deep-submodule-push.sh
+t5533-push-cas.sh
+t5534-push-signed.sh
+t5537-fetch-shallow.sh
+t5538-push-shallow.sh
+t5539-fetch-http-shallow.sh
+t5540-http-push-webdav.sh
+t5541-http-push-smart.sh
+t5542-push-http-shallow.sh
+t5543-atomic-push.sh
+t5545-push-options.sh
+t5548-push-porcelain.sh
+t5550-http-fetch-dumb.sh
+t5551-http-fetch-smart.sh
+t5552-skipping-fetch-negotiator.sh
+t5553-set-upstream.sh
+t5561-http-backend.sh
+t5570-git-daemon.sh
+t5571-pre-push-hook.sh
+t5572-pull-submodule.sh
+t5580-unc-paths.sh
+t5581-http-curl-verbose.sh
+t5582-fetch-negative-refspec.sh
+t5601-clone.sh
+t5604-clone-reference.sh
+t5605-clone-local.sh
+t5606-clone-options.sh
+t5607-clone-bundle.sh
+t5608-clone-2gb.sh
+t5609-clone-branch.sh
+t5610-clone-detached.sh
+t5611-clone-config.sh
+t5612-clone-refspec.sh
+t5614-clone-submodules-shallow.sh
+t5616-partial-clone.sh
+t5617-clone-submodules-remote.sh
+t5700-protocol-v1.sh
+t5701-git-serve.sh
+t5702-protocol-v2.sh
+t5703-upload-pack-ref-in-want.sh
+t5801-remote-helpers.sh
+t6000-rev-list-misc.sh
+t6001-rev-list-graft.sh
+t6004-rev-list-path-optim.sh
+t6006-rev-list-format.sh
+t6007-rev-list-cherry-pick-file.sh
+t6008-rev-list-submodule.sh
+t6009-rev-list-parent.sh
+t6012-rev-list-simplify.sh
+t6013-rev-list-reverse-parents.sh
+t6016-rev-list-graph-simplify-history.sh
+t6017-rev-list-stdin.sh
+t6018-rev-list-glob.sh
+t6019-rev-list-ancestry-path.sh
+t6030-bisect-porcelain.sh
+t6040-tracking-info.sh
+t6050-replace.sh
+t6101-rev-parse-parents.sh
+t6110-rev-list-sparse.sh
+t6111-rev-list-treesame.sh
+t6112-rev-list-filters-objects.sh
+t6120-describe.sh
+t6200-fmt-merge-msg.sh
+t6302-for-each-ref-filter.sh
+t6400-merge-df.sh
+t6402-merge-rename.sh
+t6404-recursive-merge.sh
+t6405-merge-symlinks.sh
+t6406-merge-attr.sh
+t6407-merge-binary.sh
+t6409-merge-subtree.sh
+t6411-merge-filemode.sh
+t6412-merge-large-rename.sh
+t6413-merge-crlf.sh
+t6414-merge-rename-nocruft.sh
+t6415-merge-dir-to-symlink.sh
+t6416-recursive-corner-cases.sh
+t6417-merge-ours-theirs.sh
+t6418-merge-text-auto.sh
+t6419-merge-ignorecase.sh
+t6422-merge-rename-corner-cases.sh
+t6425-merge-rename-delete.sh
+t6427-diff3-conflict-markers.sh
+t6430-merge-recursive.sh
+t6432-merge-recursive-space-options.sh
+t6433-merge-toplevel.sh
+t6434-merge-recursive-rename-options.sh
+t6436-merge-overwrite.sh
+t6437-submodule-merge.sh
+t6439-merge-co-error-msgs.sh
+t6501-freshen-objects.sh
+t7003-filter-branch.sh
+t7004-tag.sh
+t7030-verify-tag.sh
+t7060-wtstatus.sh
+t7063-status-untracked-cache.sh
+t7102-reset.sh
+t7113-post-index-change-hook.sh
+t7201-co.sh
+t7400-submodule-basic.sh
+t7403-submodule-sync.sh
+t7406-submodule-update.sh
+t7407-submodule-foreach.sh
+t7409-submodule-detached-work-tree.sh
+t7417-submodule-path-url.sh
+t7501-commit-basic-functionality.sh
+t7502-commit-porcelain.sh
+t7503-pre-commit-and-pre-merge-commit-hooks.sh
+t7504-commit-msg-hook.sh
+t7505-prepare-commit-msg-hook.sh
+t7508-status.sh
+t7510-signed-commit.sh
+t7512-status-help.sh
+t7517-per-repo-email.sh
+t7600-merge.sh
+t7606-merge-custom.sh
+t7608-merge-messages.sh
+t7610-mergetool.sh
+t7611-merge-abort.sh
+t7612-merge-verify-signatures.sh
+t7614-merge-signoff.sh
+t7701-repack-unpack-unreachable.sh
+t7800-difftool.sh
+t7810-grep.sh
+t8001-annotate.sh
+t8003-blame-corner-cases.sh
+t8004-blame-with-conflicts.sh
+t9001-send-email.sh
+t9100-git-svn-basic.sh
+t9145-git-svn-master-branch.sh
+t9151-svn-mergeinfo.sh
+t9155-git-svn-fetch-deleted-tag.sh
+t9156-git-svn-fetch-deleted-tag-2.sh
+t9163-git-svn-reset-clears-caches.sh
+t9169-git-svn-dcommit-crlf.sh
+t9300-fast-import.sh
+t9301-fast-import-notes.sh
+t9302-fast-import-unpack-limit.sh
+t9350-fast-export.sh
+t9351-fast-export-anonymize.sh
+t9400-git-cvsserver-server.sh
+t9401-git-cvsserver-crlf.sh
+t9402-git-cvsserver-refs.sh
+t9500-gitweb-standalone-no-errors.sh
+t9501-gitweb-standalone-http-status.sh
+t9502-gitweb-standalone-parse-output.sh
+t9600-cvsimport.sh
+t9601-cvsimport-vendor-branch.sh
+t9602-cvsimport-branches-tags.sh
+t9603-cvsimport-patchsets.sh
+t9800-git-p4-basic.sh
+t9801-git-p4-branch.sh
+t9806-git-p4-options.sh
+t9807-git-p4-submit.sh
+t9811-git-p4-label-import.sh
+t9903-bash-prompt.sh
-- 
2.29.2.222.g5d2a92d10f8

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 13, 2020

On the Git mailing list, Felipe Contreras wrote (reply to this):

On Fri, Nov 13, 2020 at 7:00 AM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> On Thu, Nov 12 2020, Johannes Schindelin via GitGitGadget wrote:

> After this series as it stands lands what's a rather big UI change in
> git isn't discussed *anywhere* in the docs.
>
> I'm not saying we need some similar s/master/main/g in Documentation/ as
> what's being done here in t/, but I think a bare minimum for a rather
> big UI change like this is:

Why not?

Isn't this change being championed on behalf of users who find the
word offensive?

Why would it be offensive to see the word on the commands you type on
the command line, but not offensive if the documentation tells you to
type those commands? This does not compute.

And worse; for the rest of the users that don't find the word
offensive (99.9% of them?), the documentation is left in an
inconsistent state, where some commands would not work as they are
stated.

If a word is so offensive it has to be erased from the Git lexicon,
then it has to be erased *everywhere*, or at least everywhere a user
might look.

Cheers.

-- 
Felipe Contreras

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 13, 2020

On the Git mailing list, Jeff King wrote (reply to this):

On Fri, Nov 13, 2020 at 05:13:20PM +0100, Ævar Arnfjörð Bjarmason wrote:

>  * A lot of tests (but a small minority of the total) have master
>    "master" hardcoded in some way. We now inventory them in
>    tests-that-need-master.txt, we can still remove the names from that
>    file and manually change the code later, but this accomplishes a
>    clean test run with a relatively easy-to-review diff.
> 
>    We ignore GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=<name> when it comes
>    to these files, unless
>    GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME_HARDER=true is set.

I'm confused how this is better. We could just be setting
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME at the top of those files, couldn't
we? (Likewise, I think annotating individual scripts is more
decentralized than a magic pattern in test-lib.sh, though it amounts to
the same thing).

And if I understand the current state of Dscho's patches, we don't
_have_ to convert any tests right now. We could just annotate those
scripts which are not yet converted to have them use the old name.

But I don't think we want to live in that state indefinitely. It's
slightly annoying to have inconsistent naming within the tests. I'd be
happy to switch individual tests at a leisurely pace over the next
couple of months or whatever. But since Dscho has bothered to write all
of the patches now, why not use them?

I'm much more concerned about the lack of documentation changes
associated with the final patch. We don't necessarily need to eradicate
every mention of "master" from the documentation, but I think we do need
to make sure that examples and instructions are consistent with how Git
will actually behave. And that does need to happen at the same time as
the user-visible flip of the default.

I'm on the fence whether there should be a deprecation period or major
version bump for the final patch, but making the tests flexible enough
to handle the before and after state seems like it can be done uncoupled
from the actual default-flip.

-Peff

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 13, 2020

User Jeff King <peff@peff.net> has been added to the cc: list.

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 13, 2020

On the Git mailing list, Johannes Schindelin wrote (reply to this):

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-78184385-1605304851=:18437
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Peff and =C3=86var,

On Fri, 13 Nov 2020, Jeff King wrote:

> On Fri, Nov 13, 2020 at 05:13:20PM +0100, =C3=86var Arnfj=C3=B6r=C3=B0 B=
jarmason wrote:
>
> >  * A lot of tests (but a small minority of the total) have master
> >    "master" hardcoded in some way. We now inventory them in
> >    tests-that-need-master.txt, we can still remove the names from that
> >    file and manually change the code later, but this accomplishes a
> >    clean test run with a relatively easy-to-review diff.
> >
> >    We ignore GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=3D<name> when it com=
es
> >    to these files, unless
> >    GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME_HARDER=3Dtrue is set.
>
> I'm confused how this is better. We could just be setting
> GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME at the top of those files, couldn't
> we? (Likewise, I think annotating individual scripts is more
> decentralized than a magic pattern in test-lib.sh, though it amounts to
> the same thing).

I considered this alternative very briefly, and rejected it immediately
because it would have implied a drawn-out limbo where the test suite will
be inconsistent. That's not what I want.

> And if I understand the current state of Dscho's patches, we don't
> _have_ to convert any tests right now. We could just annotate those
> scripts which are not yet converted to have them use the old name.

And that's what I did in some cases, see e.g. 5d5f4ea30de (t5411: finish
preparing for `main` being the default branch name, 2020-10-31).

It's just quite a ton of work to do this for all the affected test
scripts, and I wanted to automate as much as possible of that process so
that it'll be easier to cope with all the other topics that are in flight.

Therefore, I opted to "annotate the scripts" via a `case` in
`test-lib.sh`. It should be quite a bit easier to understand, too, for the
occasional reader, as it shows you the complete range of scripts that have
been handled so far.

> But I don't think we want to live in that state indefinitely. It's
> slightly annoying to have inconsistent naming within the tests. I'd be
> happy to switch individual tests at a leisurely pace over the next
> couple of months or whatever. But since Dscho has bothered to write all
> of the patches now, why not use them?

Yep, I am a bit puzzled why we need to consider other approaches. I would
have thought that the more pressing issue is to verify that I

1) caught all the necessary conversions,

2) did not miss any non-trivial adjustments (such as `naster` and aligned
   comments).

At the same time, I am quite thankful for all the help =C3=86var provided;
mentioning that I missed `naster` in t1400 was definitely super helpful.

> I'm much more concerned about the lack of documentation changes
> associated with the final patch. We don't necessarily need to eradicate
> every mention of "master" from the documentation, but I think we do need
> to make sure that examples and instructions are consistent with how Git
> will actually behave. And that does need to happen at the same time as
> the user-visible flip of the default.

I am sorry. This is totally my fault. I should have described this much
better in the cover letter. This patch series deliberately omits all the
documentation changes.

I _did_ prepare them, they are pretty much ready-to-go, as part of the
`inclusive-naming` branch I track in
https://github.com/gitgitgadget/git/pull/655 (I use the branch name
`use-main-as-default-branch-name-docs` in the `inclusive-naming` branch
thicket to track the documentation changes).

The decision to separate them out into their own patch series was made
consciously, to avoid having one big, honking, totally unreviewably large
patch series.

Therefore, just like I fed the preparatory patch series in a slow cadence,
I planned on feeding the `-docs` patch series once the dust settles on
this patch series (i.e. once it hits `next`).

> I'm on the fence whether there should be a deprecation period or major
> version bump for the final patch, but making the tests flexible enough
> to handle the before and after state seems like it can be done uncoupled
> from the actual default-flip.

Hmm. On that matter, I wonder what the big fuss is all about. It's not
like Git is forcing anybody to change their default branch. That's not at
all what we're doing. To the contrary: _after_ many projects chose to
change their default branch names, and _after_ GitHub started to follow
that trend, Git added support for `init.defaultBranch` to accommodate that
use case better. So in a sense, we're actually pretty late changing the
fall-back of `init.defaultBranch`, at least from the perspective outside
of the Git project.

There have been plenty of articles about this in the meantime, too, and
I could imagine that most developers are at least aware that the shift
away from `master` is happening, in many quite visible projects.

So to me, this whole discussion about whether this should bump the major
version of Git seems a bit overblown. It's not like the median developer
is creating new repositories on a regular basis, and if they do, chances
are that they go with whatever branch name happens to be the initial one.

What is much more common is that developers clone existing projects. And
guess what, many of those projects already use a different default branch
name. And developers seem to accept that and just go on with their lives.

If it was up to me, I would reserve a major version increment to much
bigger changes.

Ciao,
Dscho

--8323328-78184385-1605304851=:18437--

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 13, 2020

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Peff,

On Fri, 13 Nov 2020, Johannes Schindelin wrote:

> On Fri, 13 Nov 2020, Jeff King wrote:
>
> > I'm on the fence whether there should be a deprecation period or major
> > version bump for the final patch, but making the tests flexible enough
> > to handle the before and after state seems like it can be done uncoupled
> > from the actual default-flip.
>
> [...] It's not like the median developer is creating new repositories on
> a regular basis, and if they do, chances are that they go with whatever
> branch name happens to be the initial one.
>
> What is much more common is that developers clone existing projects. And
> guess what, many of those projects already use a different default branch
> name. And developers seem to accept that and just go on with their lives.

After sending off this mail, I felt a bit bad about not backing this up
with data.

Whatever telemetry I would be able to pull would not be representative,
and I would not be at liberty to share it anyway. So I asked Alex Mullans
of GitHub (who is in charge of the default branch name switch to `main`
there) whether he has any data I could share publicly and he said: "Across
GitHub, 1/4 of daily pushes (and growing) go to `main`."

Seeing as the branch name to be used in newly-created repositories on
GitHub changed only very recently (October 1st, i.e. some 6 weeks ago), I
highly suspect that this number means that _a lot_ of existing projects
have changed their primary branch name to `main`, and seem to be quite
happy with it.

All this is to say that I consider it unnecessary to have a long
deprecation period or major version bump for this patch series, based on
available public data. The name `main` is already in wide-spread use (and
growing) as primary branch name of Git projects.

Ciao,
Dscho

@gitgitgadget
Copy link

gitgitgadget bot commented Nov 13, 2020

On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):


On Fri, Nov 13 2020, Johannes Schindelin wrote:

> Hi Peff and Ævar,
>
> On Fri, 13 Nov 2020, Jeff King wrote:
>
>> On Fri, Nov 13, 2020 at 05:13:20PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
>> >  * A lot of tests (but a small minority of the total) have master
>> >    "master" hardcoded in some way. We now inventory them in
>> >    tests-that-need-master.txt, we can still remove the names from that
>> >    file and manually change the code later, but this accomplishes a
>> >    clean test run with a relatively easy-to-review diff.
>> >
>> >    We ignore GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=<name> when it comes
>> >    to these files, unless
>> >    GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME_HARDER=true is set.
>>
>> I'm confused how this is better. We could just be setting
>> GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME at the top of those files, couldn't
>> we? (Likewise, I think annotating individual scripts is more
>> decentralized than a magic pattern in test-lib.sh, though it amounts to
>> the same thing).
>
> I considered this alternative very briefly, and rejected it immediately
> because it would have implied a drawn-out limbo where the test suite will
> be inconsistent. That's not what I want.
>
>> And if I understand the current state of Dscho's patches, we don't
>> _have_ to convert any tests right now. We could just annotate those
>> scripts which are not yet converted to have them use the old name.
>
> And that's what I did in some cases, see e.g. 5d5f4ea30de (t5411: finish
> preparing for `main` being the default branch name, 2020-10-31).
>
> It's just quite a ton of work to do this for all the affected test
> scripts, and I wanted to automate as much as possible of that process so
> that it'll be easier to cope with all the other topics that are in flight.
>
> Therefore, I opted to "annotate the scripts" via a `case` in
> `test-lib.sh`. It should be quite a bit easier to understand, too, for the
> occasional reader, as it shows you the complete range of scripts that have
> been handled so far.
>
>> But I don't think we want to live in that state indefinitely. It's
>> slightly annoying to have inconsistent naming within the tests. I'd be
>> happy to switch individual tests at a leisurely pace over the next
>> couple of months or whatever. But since Dscho has bothered to write all
>> of the patches now, why not use them?
>
> Yep, I am a bit puzzled why we need to consider other approaches. I would
> have thought that the more pressing issue is to verify that I
>
> 1) caught all the necessary conversions,
>
> 2) did not miss any non-trivial adjustments (such as `naster` and aligned
>    comments).
>
> At the same time, I am quite thankful for all the help Ævar provided;
> mentioning that I missed `naster` in t1400 was definitely super helpful.

Not being up-to-date on this whole s/master/main/g discussion, is the
context here that we've essentially pre-approved these patches & doc for
integration into the next release? If so I really don't mind doing it
this way.

I started poking at this because I noticed that on git.git's master
branch tests were being skipped due to PREPARE_FOR_MAIN_BRANCH, so it's
in some in-between state between patch serieses.

We're now in week 4/9 of a release cycle for 2.30 (or 3.00 or
whatever). I hope the one thing people for & against this master/main
change can agree on is that it would be bad to ship a git with an
incomplete migration to "main", e.g. the 28/28 patch here which changes
it but without any doc updates.

I may be reading this wrong, but it seems
pr-762/dscho/use-main-as-default-branch-name-v1...remotes/dscho/inclusive-naming
(which I'm assuming is what's left) is another ~30k line diff on top of
this ~25k one.

So yes I'm very late to the discussion, sorry about that. I'm just
chiming in to say that if we're doing this as part of our regular patch
review front-loading these massive search/replace changes seems to be
too much of a change for one cycle.

But if Junio's going to chime in to say he's applying it all I don't
care & don't have any concern about it.

>> I'm much more concerned about the lack of documentation changes
>> associated with the final patch. We don't necessarily need to eradicate
>> every mention of "master" from the documentation, but I think we do need
>> to make sure that examples and instructions are consistent with how Git
>> will actually behave. And that does need to happen at the same time as
>> the user-visible flip of the default.
>
> I am sorry. This is totally my fault. I should have described this much
> better in the cover letter. This patch series deliberately omits all the

Ditto in my hastily-written RFC commit message. A better summary is:

 * Yours: All tests depend on master changed to all tests depend on main
 * Mine (well, partway there): You can set $ANY_NAME for the branch, but
   we blacklist some as being hardcoded on <name> (which I just left at
   master).

   This means we can test e.g. non-ASCII default branch names. It seems
   better to me if we're going to s/master/something/g & review it to
   have that something be \$GIT_TEST_MAIN (or another variable). Then we
   can mark that test as "accepts any default branch name" and move on.

 * Yours: Requires not running some tests while we wait for this to land
 * Mine: Run all tests & mark them as we go along for
   master||$NEWNAME. Similar to the test protocol v2 refactoring

But yeah e.g. the t/tests-that-need-master.txt I added in my RFC is
better marked in the test itself, I should have stolen your 'case
"$TEST_NUMBER"' way of doing it.

In my defense I honestly managed to miss it in skimming the ginormous
diff, which I think makes part of my argument here :)

> I _did_ prepare them, they are pretty much ready-to-go, as part of the
> `inclusive-naming` branch I track in
> https://github.com/gitgitgadget/git/pull/655 (I use the branch name
> `use-main-as-default-branch-name-docs` in the `inclusive-naming` branch
> thicket to track the documentation changes).
>
> The decision to separate them out into their own patch series was made
> consciously, to avoid having one big, honking, totally unreviewably large
> patch series.
>
> Therefore, just like I fed the preparatory patch series in a slow cadence,
> I planned on feeding the `-docs` patch series once the dust settles on
> this patch series (i.e. once it hits `next`).

On the topic of deprecation etc.:

>> I'm on the fence whether there should be a deprecation period or major
>> version bump for the final patch, but making the tests flexible enough
>> to handle the before and after state seems like it can be done uncoupled
>> from the actual default-flip.
>
> Hmm. On that matter, I wonder what the big fuss is all about. It's not
> like Git is forcing anybody to change their default branch. That's not at
> all what we're doing. To the contrary: _after_ many projects chose to
> change their default branch names, and _after_ GitHub started to follow
> that trend, Git added support for `init.defaultBranch` to accommodate that
> use case better. So in a sense, we're actually pretty late changing the
> fall-back of `init.defaultBranch`, at least from the perspective outside
> of the Git project.
>
> There have been plenty of articles about this in the meantime, too, and
> I could imagine that most developers are at least aware that the shift
> away from `master` is happening, in many quite visible projects.
>
> So to me, this whole discussion about whether this should bump the major
> version of Git seems a bit overblown. It's not like the median developer
> is creating new repositories on a regular basis, and if they do, chances
> are that they go with whatever branch name happens to be the initial one.
>
> What is much more common is that developers clone existing projects. And
> guess what, many of those projects already use a different default branch
> name. And developers seem to accept that and just go on with their lives.
>
> If it was up to me, I would reserve a major version increment to much
> bigger changes.
>
[I'm continuing quoting you here from your downthread
<nycvar.QRO.7.76.6.2011132324070.18437@tvgsbejvaqbjf.bet>]

> Whatever telemetry I would be able to pull would not be representative,
> and I would not be at liberty to share it anyway. So I asked Alex Mullans
> of GitHub (who is in charge of the default branch name switch to `main`
> there) whether he has any data I could share publicly and he said: "Across
> GitHub, 1/4 of daily pushes (and growing) go to `main`."
> 
> Seeing as the branch name to be used in newly-created repositories on
> GitHub changed only very recently (October 1st, i.e. some 6 weeks ago), I
> highly suspect that this number means that _a lot_ of existing projects
> have changed their primary branch name to `main`, and seem to be quite
> happy with it.
> 
> All this is to say that I consider it unnecessary to have a long
> deprecation period or major version bump for this patch series, based on
> available public data. The name `main` is already in wide-spread use (and
> growing) as primary branch name of Git projects.

All of that's true, but I really don't see how it's relevant to the
change we're discussing making to refs.c in git.git, which from my
generous reading of some of the threads in objection to this is the main
point of contention.

(I'm generously not engaging with some of the more howler-monkey esque
replies we've had on-list from people who seemed to have no idea what
was actually being proposed in git.git)

*That* change is not whether we approve of people using "main", or
hosting sites like GitHub etc. making it the default.

I think it's fair to say that even in some alternate universe where the
particular reasons we're switching away from "master" didn't exist and
e.g. GitHub et al had just decided on this out of the blue based on an
aesthetic preference we'd just say "uh, sure, whatever, you configure it
how you want".

Rather, we're talking about what happens when you run "git init".

Most people who are using or creating git repositories are nowadays
never going to be impacted by what "git init" does. So I think the data
you're citing here doesn't support your argument at all, it does the
opposite.

The people using these repositories with "main" on GitHub did not do so
with a patch to "git init". They clicked a button in the UI, or
copy/pasted GitHub's "how to create a local repo" which nowadays will
manually set the branch to "main" before pushing.

Then who's using "git init" who's going to be impacted by this change?
It's everyone else, like probably tens of tens of thousands of one-off
cronjobs somewhere creating a daily report of some by "init && commit &&
git diff master..".

I'm on the fence about what we should do in that case, but I'm leaning
towards some deprecation period or at least some other approach than a
s/master/main/g change precisely because of the numbers you're citing.

Because they shows how irrelevant the default shipped with git.git is to
users who want this s/master/main/g change in repositories they
regularly use. So we're really mostly talking about an impact to scripts
& some advanced users, both of who have a pretty good argument for
"init"'s default being what's been explicitly documented for ages in its
manpage.

Even if we want to just change it I think it's uncharitable to those
people not to at least consider throwing them some bone. E.g. "init"
could use the old default when it's not connected to a terminal, we
could show an advice notice and sleep(5) saying we're using a new
default etc. etc.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 6, 2021

This patch series was integrated into seen via git@efe08e5.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 7, 2021

This patch series was integrated into seen via git@30f6f31.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 7, 2021

This patch series was integrated into seen via git@aaba185.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 7, 2021

This patch series was integrated into seen via git@b3b7f06.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 7, 2021

This patch series was integrated into seen via git@61bafb6.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 8, 2021

This patch series was integrated into seen via git@14417fd.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 8, 2021

This patch series was integrated into seen via git@daef6a6.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 8, 2021

This patch series was integrated into seen via git@857d74e.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 9, 2021

This patch series was integrated into seen via git@34011a8.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 12, 2021

This patch series was integrated into seen via git@cccc3fa.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 13, 2021

This patch series was integrated into seen via git@c2340ae.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 13, 2021

This patch series was integrated into seen via git@c81baf0.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 13, 2021

This patch series was integrated into seen via git@0b9caa7.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 13, 2021

This patch series was integrated into seen via git@1861eb3.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 13, 2021

This patch series was integrated into next via git@0e93f0d.

@gitgitgadget gitgitgadget bot added the next label Jan 13, 2021
@gitgitgadget
Copy link

gitgitgadget bot commented Jan 15, 2021

This patch series was integrated into seen via git@0e93f0d.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 15, 2021

This patch series was integrated into seen via git@ec55cb8.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 15, 2021

This patch series was integrated into seen via git@0e93f0d.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 15, 2021

This patch series was integrated into seen via git@b91fd79.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 16, 2021

This patch series was integrated into seen via git@174b178.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 16, 2021

This patch series was integrated into seen via git@b2b6ecb.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 25, 2021

This patch series was integrated into seen via git@27d7c85.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 25, 2021

This patch series was integrated into next via git@27d7c85.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 25, 2021

This patch series was integrated into master via git@27d7c85.

@gitgitgadget gitgitgadget bot added the master label Jan 25, 2021
@gitgitgadget gitgitgadget bot closed this Jan 25, 2021
@gitgitgadget
Copy link

gitgitgadget bot commented Jan 25, 2021

Closed via 27d7c85.

@dscho dscho deleted the use-main-as-default-branch-name branch January 28, 2021 15:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant