RE: [PATCH v2] config: add --comment option to add a comment

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Mar 11, 2024, 16:48 UTC
Message-ID: <0b8701da73d3$fa0f2080$ee2d6180$@nexbridge.com>
In-Reply-To: <5eff951e815e2fdab3834c4aa4160ed8@manjaro.org>

On Monday, March 11, 2024 12:17 PM, Dragan Simic wrote:

Show 24 quoted lines

>Subject: Re: [PATCH v2] config: add --comment option to add a comment
>
>On 2024-03-11 13:55, Junio C Hamano wrote:
>> "Ralph Seichter via GitGitGadget" <gitgitgadget@gmail.com> writes:
>>
>>> From: Ralph Seichter <github@seichter.de>
>>>
>>> Introduce the ability to append comments to modifications made using
>>> git-config. Example usage:
>>>
>>>   git config --comment "changed via script" \
>>>     --add safe.directory /home/alice/repo.git
>>>
>>> based on the proposed patch, the output produced is:
>>>
>>>   [safe]
>>>     directory = /home/alice/repo.git #changed via script
>>
>> For readability, you probably would want to have a SP before the given
>> string, i.e.,
>>
>> 	variable = "value" # message comes here
>
>Let me interject...  Perhaps also a tab character before the "# comment",

instead of a space character.  That would result in even better

>readability.

Does adding a tab following data change the parse semantics of .gitconfig? My naïve understanding is that .gitconfig follows a basic rule of leading tab within a section, followed by text. Is there a formal syntax description of what valid input is? The value does not need to be quoted, so what does the following actually resolve to:

(TAB)variable = value(TAB)# comment.

Does variable mean value or value(TAB)? Obviously TABS should be correctly be interpreted as whitespace to be ignored. However, what about:

(TAB)variable = value(TAB)s(TAB) # comment.

Does that mean value(TAB)s, value(TAB)s(TAB), value s, value s(TAB), values?

The definition according to git-config is

"The syntax is fairly flexible and permissive; whitespaces are mostly ignored. The # and ; characters begin comments to the end of line, blank lines are ignored."

"Mostly" does not make me comfortable that this is formally allowed or disallowed or ignored. I would suggest that this change needs to formalize the grammar on that documentation page for clarity.