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

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

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

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.

So, I dunno.

Thanks.

[Footnote]

 * Essentially we would need to collect all information (like hook
   output and template files) before we produce our own message to
   be commented out because we need to know what symbol is
   available.  Such a change may mean a major reshuffling of some
   code paths (or worse, some code paths may have to be made to fail
   and retry).  As long as the damage is limited to the case where
   "auto" setting is used, such a "solution" is acceptable.