From: Phillip Wood <phillip.wood123@gmail.com>
Date: Wed, 09 Jul 2025 09:40:34 GMT
Subject: Re: [PATCH 1/2] breaking-changes: deprecate support for core.commentString=auto
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:
> 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

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