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

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Jul 9, 2025, 09:38 UTC
Message-ID: <f1fad7f4-209f-47a9-8ad2-5e236c0b0006@gmail.com>
In-Reply-To: <xmqqy0syp30y.fsf@gitster.g>

On 09/07/2025 02:27, Junio C Hamano wrote:

Show 11 quoted lines

> Phillip Wood <phillip.wood123@gmail.com> 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

Show 14 quoted lines

> 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