Re: [PATCH] docs: clarify meaning of core.commentString=auto

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Mar 20, 2025, 10:21 UTC
Message-ID: <6a3154e0-e7bc-45ae-b554-67ccab18727a@gmail.com>
In-Reply-To: <Z9sLAEbE9lAInBXz@ugly>

On 19/03/2025 18:20, Oswald Buddenhagen wrote:

Show 9 quoted lines

> On Tue, Mar 18, 2025 at 10:15:15AM -0700, Junio C Hamano wrote:
>>> reading through the thread of the original submission, the feature is a
>>> workaround for `commit -m` and `commit --amend` being inconsistent wrt.
>>> message washing.
>>
>> Perhaps somebody can be talked into fixing it ;-)
>>
>> With a clear explanation, I am OK if somebody wants to advocate to
>> deprecate (and remove at Git 3.0 boundary) the "auto" support ;-)

I think that may be best. Looking at the sequencer I don't think append_conflicts_hint(), the "fixup" or "squash" commands of "rebase -i", or the "--reference" option of "git revert" are compatible with core.commentStr=auto. For rebase making it work would mean scanning the messages of all the commits to be squash before picking the first one which is a pain.

> how would we go about this in practice? just a notice in the docu, or
> some mechanism which would complain at runtime? under what circumstances
> (i.e., how to enable/squelch it)?

I think we'd want to start printing some advice when core.commentStr=auto explaining why it has been deprecated and that it will be removed when Git 3.0 is released. We should allow that advice to be suppressed setting advice.autoCommentStr (other name suggestions welcome). We would also want to add an item to BreakingChanges.adoc explaining why it is being removed and add "#ifndef WITH_BREAKING_CHANGES" around the code that handles core.commentStr=auto in builtin/commit.c and guard the documentation with "ifdef::with_breaking_changes[]". We may want to make core.commentStr=auto an error when breaking changes are enabled as well.

Best Wishes

Phillip