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

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

Eric Sunshine <sunshine@sunshineco.com> writes:

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