On 09/07/2025 02:27, Junio C Hamano 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
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
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
