Re: [PATCH 0/2] breaking-changes: deprecate support for core.commentChar=auto

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 8, 2025, 18:51 UTC
Message-ID: <xmqqjz4iv7mt.fsf@gitster.g>
In-Reply-To: <cover.1751983009.git.phillip.wood@dunelm.org.uk>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 17 quoted lines

> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> This series implements the plan to deprecate and remove support for
> core.commentChar=auto outlined in [1]. This feature has been the
> source of a couple of bug reports recently [2,3] and as explained in
> the first patch the design is tricky to fix. When git sees the
> deprecated config setting it will print advice like the example below
> to help the user either remove the setting or set a custom comment
> string.
>
> hint: Support for 'core.commentChar=auto' is deprecated and will be removed in git 3.0
> hint:
> hint: To use the default comment string (#) please run
> hint:
> hint:     git config unset --file ~/.config/git/config --all core.commentString
> hint:     git config unset --file ~/.config/git/config core.commentChar
> hint:     git config unset --global core.commentChar

We'd need to clear both variants from all scopes, wouldn't we?

	for scope in "" --local --global --worktree
	do
		for variant in commentString commentChar
		do
			git config unset $scope --all core.$variant
		done
	done

Show 6 quoted lines

> hint:
> hint: To set a custom comment string please run
> hint:
> hint:     git config set --global core.commentChar <comment string>
> hint:
> hint: where '<comment string>' is the string you wish to use.

I do not particulary find it sensible to nudge users to use the same commentChar across all projects with possibly different project conventions by suggesting use of the --global option here.

It would be necessary to special case "auto" after 3.0 boundary anyway, whether we (1) die when we notice the value is set to "auto", and refuse to work until the user chooses a comment char, or (2) use "#" or something hardcoded. Either would be better than using literal string "auto" as comment char.

So, a simpler approach might be to treat literal string "auto" as if "#" was specified under WITH_BREAKING_CHANGES so that the end-user does not have to do anything when they want to "revert" to the default comment string. Then we do not have to give any large text like the above. We can instead say something like

	The 'auto' setting of core.commentChar (or core.commentString) 
	will change its meaning in Git 3.0 and later and will always
	use the default '#'.

Hmm?

Show 23 quoted lines

> [1] https://lore.kernel.org/git/6a3154e0-e7bc-45ae-b554-67ccab18727a@gmail.com
> [2] https://lore.kernel.org/git/20250315140913.577404-1-oswald.buddenhagen@gmx.de
> [3] https://lore.kernel.org/git/20250626132233.414789-1-ayu.chandekar@gmail.com
>
> Base-Commit: f0135a9047ca37d4d117dcf21f7e3e89fad85d00
> Published-As: https://github.com/phillipwood/git/releases/tag/pw%2Fremove-auto-comment-char%2Fv1
> View-Changes-At: https://github.com/phillipwood/git/compare/f0135a904...83d0d3ece
> Fetch-It-Via: git fetch https://github.com/phillipwood/git pw/remove-auto-comment-char/v1
>
>
> Phillip Wood (2):
>   breaking-changes: deprecate support for core.commentString=auto
>   commit: print advice when core.commentString=auto
>
>  Documentation/BreakingChanges.adoc |   4 +
>  Documentation/config/core.adoc     |  20 ++-
>  builtin/commit.c                   | 192 +++++++++++++++++++++++++++++
>  config.c                           |   4 +
>  environment.c                      |   2 +
>  environment.h                      |   2 +
>  t/t3404-rebase-interactive.sh      |   2 +-
>  t/t7502-commit-porcelain.sh        |  32 ++++-
>  8 files changed, 252 insertions(+), 6 deletions(-)