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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024-03-11 17:48, rsbecker@xxxxxxxxxxxxx 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@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?

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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux