On Wed, Jul 9, 2025 at 6:57 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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 > The failing test is a test which I added in the bug-fix patch: [1] I don't understand what you meant by "treating auto too literally". > 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. [1]: https://lore.kernel.org/git/20250630182527.69167-1-ayu.chandekar@xxxxxxxxx
