Re: [PATCH 0/2] breaking-changes: deprecate support for core.commentChar=auto

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 11, 2025, 17:07 UTC
Message-ID: <xmqqsej21wsq.fsf@gitster.g>
In-Reply-To: <b811a0dc-fb49-4f66-a9ae-89a45d7ff104@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 11 quoted lines

>> If the "auto" comes from /etc/gitconfig then we'd recommend
>> changing it there, instead of overriding it per-user in ~/.gitconfig?
>
> Yes, though I'm on the fence about that. I wonder if we should
> recommend ~/.gitconfig instead if the user account that git is running
> under does not have write access to /etc/gitconfig. That also raises
> the question of what advice we should give about clearing settings in
> the system config file if the user does not have write access to
> it. It is possible the human user has write access to the system
> config even if the user account that git is running under does not but
> we have no way of finding that out.

Isn't it last-one-wins? How about just telling them to do without any "git config unset" and just do a single "git config set", either to the repository (when the "auto" we saw came from the repository) or to the per-user configuration (when the "auto" we saw came from elsewhere, either per-user, or system-wide)?

Show 10 quoted lines

>>>> It would be necessary to special case "auto" after 3.0 boundary
>>>> anyway, whether we (1) die when we notice the value is set to
>>>> "auto", and refuse to work until the user chooses a comment char, or
>>>> (2) use "#" or something hardcoded.  Either would be better than
>>>> using literal string "auto" as comment char.
>
> I'm leaning towards dying to avoid any nasty surprises when the commit
> message contains lines beginning with '#'.
>
> I'll try and re-roll next week

Thanks!