Re: [PATCH v3] config: add --comment option to add a comment

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 15, 2024, 23:41 UTC
Message-ID: <xmqqttl7njv2.fsf@gitster.g>
In-Reply-To: <CAPig+cQwWu=FA4vnKK9+aLkTzAzMXp6h5aJedEh3FT+1bNTjAQ@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 8 quoted lines

> tackled by this patch. Do we foresee a future in which git-config may
> be extended to handle automation of comments other than inline? If so,
> do we really want to lock ourselves into having the generic option
> `--comment=<message>` be restricted to only inline comments? Or would
> it be better to plan for the future by instead having some sort of
> annotation which indicates that we are requesting (or dealing with)
> only inline comments, such as `--inline-comment=<message>` or
> `--comment=inline:<message>`?

I do not see a need for anything, while we fail a request with a multi-line message and say "don't feed me a multi-line message".

When we start supporting multi-line comment (which I do not think is a good idea at all, by the way), the code can switch between

	[vari]
		able = value # single line comment
		# a comment with
		# more than one line
		able = value

depending on what is in <message>, so "inline:" prefix does not even have to exist, I would imagine. Of course you could even go fancier and allow something like this with unnecessary tailing LF ...

	$ git config --comment='another single line comment
	'

... as a signal to turn a single line commet on a separate line.

	[vari]
		able = value # single line comment
		# a comment with
		# more than one line
		able = value
		# another single value comment
		able = value

There will most likely need where e.g., above or below, around the "var = val" line to place the comment as well, so I do not see much value in investing more brain cycles on what the "--comment" option should look like, while we only support single-liners and explicitly reject multi-line messages.