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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 9, 2025, 16:20 UTC
Message-ID: <xmqqfrf5nxnq.fsf@gitster.g>
In-Reply-To: <f679151a-c843-44d4-9e28-27112d26f30c@gmail.com>

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

> With hindsight I should have been clearer here that the advice given
> is based on the user's config settings.

Ahh, OK. If the "hint" advice message gets generated with custom sequence of commands, that explains why the sample looked so uneven. Disregard what I said about clearing every variant from every scope.

> The advice will recommend a command that updates commentChar in the
> scope where it is currently set so if it is set globally it will not
> prompt you to set it locally in each repository and if it is set
> locally it will prompt you to update it there.

Again, I misunderstood the set-up that would lead to the sample output. If the user has "auto" in ~/.gitconfig, replacing it at the same place may make sense.

If the "auto" comes from /etc/gitconfig then we'd recommend changing it there, instead of overriding it per-user in ~/.gitconfig?

Show 8 quoted lines

>> 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.
>
> We can do that if you've changed your view from
> <xmqqfrj6vfsn.fsf@gitster.g>

Yeah, I think using "auto " as comment line prefix is simply a nonsense. Thanks.

Show 12 quoted lines

>> 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 '#'.
>
> That's certainly simpler for us but it does not help the user to
> update their config. Presumably they're using the auto commentchar
> because '#' does not work for them.

OK. But those with "auto" because '#' did not work for them are setting "auto" not because '#' does not work, but because none of these "#;@!$%^&|:" work for them, no?

As you said earlier, the "auto" setting cannot fundamentally work at all if we let a third-party inject any commented material into the editor buffer. The comment we inject ourselves we can control (and notice), and perhaps back in the simpler days when "auto" setting was invented, it was sufficient. But that may be no longer true, so it may not be just "tricky to fix" but simply "unworkable". From that point of view, as long as the reason clearly is explained to end-users, I am fine with "'auto' stops Git and you'd need to unset or set it to something else at the 3.0 boundary".

Thanks.