From: Junio C Hamano <gitster@pobox•com>
To: Phillip Wood <phillip.wood123@gmail•com>
Cc: git@vger•kernel.org, Ayush Chandekar <ayu.chandekar@gmail•com>,
Oswald Buddenhagen <oswald.buddenhagen@gmx•de>,
Taylor Blau <me@ttaylorr•com>,
Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail•com>
Subject: Re: [PATCH 0/2] breaking-changes: deprecate support for core.commentChar=auto
Date: Tue, 08 Jul 2025 11:51:06 -0700 [thread overview]
Message-ID: <xmqqjz4iv7mt.fsf@gitster.g> (raw)
In-Reply-To: <cover.1751983009.git.phillip.wood@dunelm.org.uk> (Phillip Wood's message of "Tue, 8 Jul 2025 14:56:50 +0100")
Phillip Wood <phillip.wood123@gmail•com> writes:
> 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
> 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?
> [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(-)
next prev parent reply other threads:[~2025-07-08 18:51 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-08 13:56 [PATCH 0/2] breaking-changes: deprecate support for core.commentChar=auto Phillip Wood
2025-07-08 13:56 ` [PATCH 1/2] breaking-changes: deprecate support for core.commentString=auto Phillip Wood
2025-07-08 15:28 ` Ayush Chandekar
2025-07-09 9:40 ` Phillip Wood
2025-07-08 13:56 ` [PATCH 2/2] commit: print advice when core.commentString=auto Phillip Wood
2025-07-08 18:51 ` Junio C Hamano [this message]
2025-07-09 9:38 ` [PATCH 0/2] breaking-changes: deprecate support for core.commentChar=auto Phillip Wood
2025-07-09 16:20 ` Junio C Hamano
2025-07-11 15:09 ` Phillip Wood
2025-07-11 17:07 ` Junio C Hamano
2025-07-12 8:01 ` Oswald Buddenhagen
2025-07-12 14:06 ` Junio C Hamano
2025-07-26 23:15 ` Junio C Hamano
2025-07-27 15:46 ` Phillip Wood
2025-07-09 1:27 ` Junio C Hamano
2025-07-09 1:52 ` Ayush Chandekar
2025-07-09 9:38 ` Phillip Wood
2025-07-31 15:21 ` [PATCH v2 0/3] " Phillip Wood
2025-07-31 15:21 ` [PATCH v2 1/3] breaking-changes: deprecate support for core.commentString=auto Phillip Wood
2025-07-31 20:49 ` Junio C Hamano
2025-07-31 15:21 ` [PATCH v2 2/3] config: warn on core.commentString=auto Phillip Wood
2025-07-31 21:17 ` Junio C Hamano
2025-08-01 10:37 ` Phillip Wood
2025-08-01 14:36 ` Oswald Buddenhagen
2025-07-31 15:21 ` [PATCH v2 3/3] commit: print advice when core.commentString=auto Phillip Wood
2025-08-01 15:18 ` Oswald Buddenhagen
2025-08-01 17:19 ` Junio C Hamano
2025-08-26 13:33 ` Phillip Wood
2025-08-27 8:19 ` Oswald Buddenhagen
2025-08-27 16:39 ` Junio C Hamano
2025-08-27 22:38 ` Oswald Buddenhagen
2025-08-01 3:50 ` [PATCH v2 0/3] breaking-changes: deprecate support for core.commentChar=auto Junio C Hamano
2025-08-01 10:36 ` Phillip Wood
2025-08-01 16:41 ` Junio C Hamano
2025-08-26 13:35 ` [PATCH v3 " Phillip Wood
2025-08-26 13:35 ` [PATCH v3 1/3] breaking-changes: deprecate support for core.commentString=auto Phillip Wood
2025-08-26 13:35 ` [PATCH v3 2/3] config: warn on core.commentString=auto Phillip Wood
2025-08-26 15:52 ` Junio C Hamano
2025-08-27 15:29 ` Phillip Wood
2025-08-27 18:55 ` Junio C Hamano
2025-08-26 13:35 ` [PATCH v3 3/3] commit: print advice when core.commentString=auto Phillip Wood
2025-08-27 15:27 ` [PATCH v4 0/3] breaking-changes: deprecate support for core.commentChar=auto Phillip Wood
2025-08-27 15:27 ` [PATCH v4 1/3] breaking-changes: deprecate support for core.commentString=auto Phillip Wood
2025-08-27 15:27 ` [PATCH v4 2/3] config: warn on core.commentString=auto Phillip Wood
2025-08-27 15:27 ` [PATCH v4 3/3] commit: print advice when core.commentString=auto Phillip Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqjz4iv7mt.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=ayu.chandekar@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=kristofferhaugsbakk@fastmail$(echo .)com \
--cc=me@ttaylorr$(echo .)com \
--cc=oswald.buddenhagen@gmx$(echo .)de \
--cc=phillip.wood123@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox