Re: [RFC/PATCH v2 3/3] status: introduce status.displayCommentChar to disable display of #

Matthieu Moy [off-list ref] writes:

Junio C Hamano [off-list ref] writes:

quoted

Matthieu Moy [off-list ref] writes:

quoted

diff --git a/Documentation/config.txt b/Documentation/config.txt
index ec57a15..dacf4b9 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt

@@ -2118,6 +2118,11 @@ status.branch::
 	Set to true to enable --branch by default in linkgit:git-status[1].
 	The option --no-branch takes precedence over this variable.
 
+status.displayCommentChar::
+	If set to false, linkgit:git-status[1] will not prefix each
+	line with the comment char (`core.commentchar`, i.e. `#` by
+	default). Defaults to true.

We prefix core.commentchar followed by a single space for non-empty
lines; is that worth mentioning, I wonder?

(and sometimes # is followed by a tab)

I don't think it's worth the trouble. The goal is not to document the
format precisely, but to explain the user how to use the variable.

quoted

Also I envision that we would extend core.commentchar to be more
than a single character.  Is "displayCommentChar" still a good name
for this setting?

It is as good as core.commentChar ;-).

Not really; taken together with "# has a space after it", calling
it "prefix" in the mechanism to omit it makes tons of sense.

quoted

What are our plans to help existing scripts people have written over
time, especially before "status -s" was invented, that will be
broken by use of this?

I don't know what's the best plan, but I think any sensible plan starts
by waiting for a few releases, so that Git version not implementing
status.displayCommentChar become rare enough. So we can delay the actual
plan until next year I guess.

Actually as Peff pointed out, we've already told number of times
that "status" output is for human consumption and scripts should not
attempt to parse it, long before we gave them -s/--porcelain
options, so we are good without "auto".