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

From: Phillip Wood <[email-masked]>
Date: Wed, 9 Jul 2025 10:38:00 +0100

On 09/07/2025 02:27, Junio C Hamano wrote:
> Phillip Wood <[email-masked]> writes:
> 
>> 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.
> 
> FWIW, this fails some tests that expect "# commented lines" by
> treating "auto" too literally.
> 
> https://github.com/git/git/actions/runs/16157263228/job/45602188411#step:10:2970

That's a semantic conflict between this series and seen - the test 
should be marked !WITH_BREAKING_CHANGES as it is testing 
core.commentChar=auto
> I wonder if our braincycles are better spent to actually perform the
> "tricky"[*] fix than deprecating the feature and then perfecting the
> deprecation process (which does not seem to be without cost either).
> 
>   - We can and should keep the "auto" magic and use '#' when it gets
>     specified, if we really wanted to do this deprecation.  I am not
>     a huge fan of it, though.
> 
>   - Or leave it as a known-broken feature in certain corner cases,
>     which may motivate some future developers to tackle these
>     "tricky" code paths.  If we were to go this route, the first step
>     would be to document what works and what does not as "known
>     limitations".  I am slightly more in favor of this than "we punt,
>     because we cannot fix it", but not by a large margin.

I've thought about fixing it but I don't see a good way for templates 
and hooks to say "lines that begin with this character are comments" - 
for a hook the choice of comment char needs to be based on the message 
so we cannot use a fixed config setting. Unless we have a way of doing 
that it is never going to work. The cherry-pick/rebase issues could be 
addressed by writing some state that is then read by "git commit" though 
goodness knows how we'd make that work with the prepare-commit-msg hook 
that wants to introduce its own comments. I don't really see the point 
of just fixing the rebase case if templates and hooks are still broken.

Now that the commentChar can be an arbitrary string rather than just a 
single byte I think is much easier for users to pick something unique 
that isn't going to be at the start of a line in their commit messages.

Best Wishes

Phillip