Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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.
