All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: git@vger.kernel.org, j.sixt@viscovery.net
Subject: Re: [RFC/PATCH v2 3/3] status: introduce status.displayCommentChar to disable display of #
Date: Wed, 28 Aug 2013 14:53:07 -0700	[thread overview]
Message-ID: <xmqqeh9d8ou4.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <vpq61up5y5s.fsf@anie.imag.fr> (Matthieu Moy's message of "Wed, 28 Aug 2013 22:59:59 +0200")

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> 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.

>> 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".

  reply	other threads:[~2013-08-28 21:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-28  8:32 [RFC/PATCH] status: introduce status.displayCommentChar to disable display of # Matthieu Moy
2013-08-28 11:03 ` Johannes Sixt
2013-08-28 12:43   ` Matthieu Moy
2013-08-28 12:47     ` [RFC/PATCH v2 1/3] builtin/stripspace.c: fix broken indentation Matthieu Moy
2013-08-28 12:47       ` [RFC/PATCH v2 2/3] submodule: introduce --[no-]display-comment-char Matthieu Moy
2013-08-28 21:07         ` Jens Lehmann
2013-08-29  7:04           ` Matthieu Moy
2013-08-28 12:47       ` [RFC/PATCH v2 3/3] status: introduce status.displayCommentChar to disable display of # Matthieu Moy
2013-08-28 20:05         ` Junio C Hamano
2013-08-28 20:10           ` Junio C Hamano
2013-08-28 20:18           ` Jeff King
2013-08-28 21:39             ` Junio C Hamano
2013-08-28 21:59               ` David Aguilar
2013-08-28 22:41                 ` Junio C Hamano
2013-08-29  6:58                 ` Matthieu Moy
2013-08-31  0:00             ` brian m. carlson
2013-08-28 20:59           ` Matthieu Moy
2013-08-28 21:53             ` Junio C Hamano [this message]
2013-08-28 21:50         ` Junio C Hamano
2013-08-28 23:13         ` Jonathan Nieder
2013-08-29  6:50           ` Matthieu Moy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqeh9d8ou4.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=j.sixt@viscovery.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.