From: Dragan Simic Date: Mon, 11 Mar 2024 17:52:21 GMT Subject: Re: [PATCH v2] config: add --comment option to add a comment Message-ID: <0f3a39ab1eeb28201b474afb7fd92c89@manjaro.org> In-Reply-To: On 2024-03-11 18:00, Dragan Simic wrote: > 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" writes: >>>> >>>>> From: Ralph Seichter >>>>> >>>>> 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). Hmm, after having a look at config.c and doing some testing, git-config(1) seems to be wrong when it says that "internal whitespaces within the value are retained verbatim". Here's an example... I placed the following into ~/.gitconfig: [test] blah = huh uh There's a tab character between "huh" and "uh". Though, running git config --get test.blah produces huh uh which contains a space character, not a tab. That's expected according to config.c, but not according to git-config(1). Should we correct the wording in git-config(1) accordingly? >> 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... After some testing, I can confirm that any tabs (or spaces, or mixes) between the value and the "#" character do get 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. > > ... I do agree that it should be clarified further in the man page.