Re: [RFC/PATCH v2 3/3] status: introduce status.displayCommentChar to disable display of #
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 28, 2013, 21:53 UTC
- Message-ID
- <xmqqeh9d8ou4.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <vpq61up5y5s.fsf@anie.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
Show 30 quoted lines
> Junio C Hamano <gitster@pobox.com> writes: > >> Matthieu Moy <Matthieu.Moy@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[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. > >> 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.
Show 8 quoted lines
>> 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".