From: Phillip Wood <phillip.wood123@gmail•com>
To: Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org, Ayush Chandekar <ayu.chandekar@gmail•com>,
Oswald Buddenhagen <oswald.buddenhagen@gmx•de>,
Taylor Blau <me@ttaylorr•com>,
Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail•com>
Subject: Re: [PATCH 0/2] breaking-changes: deprecate support for core.commentChar=auto
Date: Fri, 11 Jul 2025 16:09:17 +0100 [thread overview]
Message-ID: <b811a0dc-fb49-4f66-a9ae-89a45d7ff104@gmail.com> (raw)
In-Reply-To: <xmqqfrf5nxnq.fsf@gitster.g>
On 09/07/2025 17:20, Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@gmail•com> writes:
>
>> With hindsight I should have been clearer here that the advice given
>> is based on the user's config settings.
>
> Ahh, OK. If the "hint" advice message gets generated with custom
> sequence of commands, that explains why the sample looked so uneven.
> Disregard what I said about clearing every variant from every scope.
>
>> The advice will recommend a command that updates commentChar in the
>> scope where it is currently set so if it is set globally it will not
>> prompt you to set it locally in each repository and if it is set
>> locally it will prompt you to update it there.
>
> Again, I misunderstood the set-up that would lead to the sample
> output. If the user has "auto" in ~/.gitconfig, replacing it at the
> same place may make sense.
>
> 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.
>>> 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
Phillip
next prev parent reply other threads:[~2025-07-11 15:09 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-08 13:56 [PATCH 0/2] breaking-changes: deprecate support for core.commentChar=auto Phillip Wood
2025-07-08 13:56 ` [PATCH 1/2] breaking-changes: deprecate support for core.commentString=auto Phillip Wood
2025-07-08 15:28 ` Ayush Chandekar
2025-07-09 9:40 ` Phillip Wood
2025-07-08 13:56 ` [PATCH 2/2] commit: print advice when core.commentString=auto Phillip Wood
2025-07-08 18:51 ` [PATCH 0/2] breaking-changes: deprecate support for core.commentChar=auto Junio C Hamano
2025-07-09 9:38 ` Phillip Wood
2025-07-09 16:20 ` Junio C Hamano
2025-07-11 15:09 ` Phillip Wood [this message]
2025-07-11 17:07 ` Junio C Hamano
2025-07-12 8:01 ` Oswald Buddenhagen
2025-07-12 14:06 ` Junio C Hamano
2025-07-26 23:15 ` Junio C Hamano
2025-07-27 15:46 ` Phillip Wood
2025-07-09 1:27 ` Junio C Hamano
2025-07-09 1:52 ` Ayush Chandekar
2025-07-09 9:38 ` Phillip Wood
2025-07-31 15:21 ` [PATCH v2 0/3] " Phillip Wood
2025-07-31 15:21 ` [PATCH v2 1/3] breaking-changes: deprecate support for core.commentString=auto Phillip Wood
2025-07-31 20:49 ` Junio C Hamano
2025-07-31 15:21 ` [PATCH v2 2/3] config: warn on core.commentString=auto Phillip Wood
2025-07-31 21:17 ` Junio C Hamano
2025-08-01 10:37 ` Phillip Wood
2025-08-01 14:36 ` Oswald Buddenhagen
2025-07-31 15:21 ` [PATCH v2 3/3] commit: print advice when core.commentString=auto Phillip Wood
2025-08-01 15:18 ` Oswald Buddenhagen
2025-08-01 17:19 ` Junio C Hamano
2025-08-26 13:33 ` Phillip Wood
2025-08-27 8:19 ` Oswald Buddenhagen
2025-08-27 16:39 ` Junio C Hamano
2025-08-27 22:38 ` Oswald Buddenhagen
2025-08-01 3:50 ` [PATCH v2 0/3] breaking-changes: deprecate support for core.commentChar=auto Junio C Hamano
2025-08-01 10:36 ` Phillip Wood
2025-08-01 16:41 ` Junio C Hamano
2025-08-26 13:35 ` [PATCH v3 " Phillip Wood
2025-08-26 13:35 ` [PATCH v3 1/3] breaking-changes: deprecate support for core.commentString=auto Phillip Wood
2025-08-26 13:35 ` [PATCH v3 2/3] config: warn on core.commentString=auto Phillip Wood
2025-08-26 15:52 ` Junio C Hamano
2025-08-27 15:29 ` Phillip Wood
2025-08-27 18:55 ` Junio C Hamano
2025-08-26 13:35 ` [PATCH v3 3/3] commit: print advice when core.commentString=auto Phillip Wood
2025-08-27 15:27 ` [PATCH v4 0/3] breaking-changes: deprecate support for core.commentChar=auto Phillip Wood
2025-08-27 15:27 ` [PATCH v4 1/3] breaking-changes: deprecate support for core.commentString=auto Phillip Wood
2025-08-27 15:27 ` [PATCH v4 2/3] config: warn on core.commentString=auto Phillip Wood
2025-08-27 15:27 ` [PATCH v4 3/3] commit: print advice when core.commentString=auto Phillip Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b811a0dc-fb49-4f66-a9ae-89a45d7ff104@gmail.com \
--to=phillip.wood123@gmail$(echo .)com \
--cc=ayu.chandekar@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=kristofferhaugsbakk@fastmail$(echo .)com \
--cc=me@ttaylorr$(echo .)com \
--cc=oswald.buddenhagen@gmx$(echo .)de \
--cc=phillip.wood@dunelm$(echo .)org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox