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