Re: [PATCH v2] config: add --comment option to add a comment
- From
- Dragan Simic <dsimic@manjaro.org>
- Date
- Mar 11, 2024, 17:00 UTC
- Message-ID
- <e7fe2e229f0b5c76fdec1d789bfecd6e@manjaro.org>
- In-Reply-To
- <0b8701da73d3$fa0f2080$ee2d6180$@nexbridge.com>
On 2024-03-11 17:48, rsbecker@nexbridge.com wrote:
Show 50 quoted lines
> 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).
Show 6 quoted lines
> 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.