Re: [PATCH 1/2] breaking-changes: deprecate support for core.commentString=auto
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Jul 9, 2025, 09:40 UTC
- Message-ID
- <2b0ddaf6-9242-47b5-914a-73fdd1dde4a4@gmail.com>
- In-Reply-To
- <CAE7as+YyKHzHjpCn2fFym0e5JquhroeDPHo_FHtdNCCb1HVSgw@mail.gmail.com>
Hi Ayush
On 08/07/2025 16:28, Ayush Chandekar wrote:
Show 14 quoted lines
> On Tue, Jul 8, 2025 at 7:27 PM Phillip Wood <phillip.wood123@gmail.com> wrote: >> >> When "core.commentString" is set to "auto" then "git commit" >> will automatically select the comment character ensuring that it >> does not the first character on any of the lines in the commit >> message. This was introduced by commit 84c9dc2c5a2 (commit: allow >> core.commentChar=auto for character auto selection, 2014-05-17) The >> motivation seems to be to avoid commenting out lines from the existing >> message when amending a commit that was created with a message from >> a file. >> > > s/that it does not the first character/that it does not appear on the > first character?
Well spotted - I was trying to change it say "that it is not the first character" but edited the message badly
Show 29 quoted lines
>> Unfortunately this feature does not work with: >> >> * commit message templates that contain comments. >> >> * prepare-commit-msg hooks that introduce comments. >> >> * "git commit --cleanup=strip --edit -F <file>" which means that it >> is incompatible with >> >> - the "fixup" and "squash" commands of "git rebase -i" as the >> comments added by those commands are then treated as part of the >> commit message. >> >> - the conflict comments added to the commit message by "git >> cherry-pick", "git rebase" etc. as these comments are then treated >> as part of the commit message. >> >> It is also ignored by "git notes" when amending a note. >> >> The issues with comments coming from a template, hook or file are a >> consequence of the design of this feature and are therefore hard to >> fix. >> >> As the costs of this feature outweigh the benefits deprecate it and >> remove it in Git 3.0. If someone comes up with some patches that fix all >> the issues in a maintainable way then I'd be happy to see this change >> reverted. >> > Nit: s/benefits deprecate/benefits, deprecate.
Good idea
Thanks
Phillip