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

> On 2024-03-11 17:48, rsbecker@nexbridge.com wrote:
>> On Monday, March 11, 2024 12:17 PM, Dragan Simic wrote:
>>> 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?
> 
> It should mean "value(TAB)s", according to git-config(1).

>> 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."
> 
> I believe these two quotations from git-config(1) should make it more 
> clear:
> 
>     A line that defines a value can be continued to the next line by 
> ending
>     it with a \; the backslash and the end-of-line are stripped. 
> Leading
>     whitespaces after name =, the remainder of the line after the first
>     comment character # or ;, and trailing whitespaces of the line are
>     discarded unless they are enclosed in double quotes.  Internal
>     whitespaces within the value are retained verbatim.
> 
>     The following escape sequences (beside \" and \\) are recognized: 
> \n
>     for newline character (NL), \t for horizontal tabulation (HT, TAB) 
> and
>     \b for backspace (BS). Other char escape sequences (including octal
>     escape sequences) are invalid.
> 
> To me, all that indicates that trailing tab characters are stripped, 
> but...

>> "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.
> 
> ... I do agree that it should be clarified further in the man page.