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

[Junio C Hamano <gitster@pobox.com>]

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

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

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