On 2024-03-11 18:00, Dragan Simic wrote:
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).
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.
