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

>
> 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.