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@xxxxxxxxx> writes: >> >>> From: Ralph Seichter <github@xxxxxxxxxxx> >>> >>> 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.
