Matthieu Moy <matthieu....@grenoble-inp.fr> writes:
> Junio C Hamano <gits...@pobox.com> writes:
>> Matthieu Moy <matthieu....@imag.fr> writes:
>>> 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.
>>> The option --no-branch takes precedence over this variable.
>>> + If set to false, linkgit:git-status 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.
>> 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.
>> 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".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html