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

From: Dragan Simic <[email-masked]>
Date: Mon, 11 Mar 2024 18:00:40 +0100

On 2024-03-11 17:48, [email-masked] 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" <[email-masked]> writes:
>>> 
>>>> From: Ralph Seichter <[email-masked]>
>>>> 
>>>> 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.