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

Eric Sunshine [off-list ref] 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.