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

From: Junio C Hamano <[email-masked]>
Date: Wed, 28 Aug 2013 15:41:47 -0700

David Aguilar <[email-masked]> writes:

> On Wed, Aug 28, 2013 at 2:39 PM, Junio C Hamano <[email-masked]> wrote:
>> Jeff King <[email-masked]> writes:
>>
>>> On Wed, Aug 28, 2013 at 01:05:38PM -0700, Junio C Hamano wrote:
>>>
>>>> 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 thought that our response to parsing the long output of "git status"
>>> was always "you are doing it wrong". The right way has always been to
>>> run the plumbing tools yourself, followed eventually by the --porcelain
>>> mode to "git status" being blessed as a convenient plumbing.
>>>
>>> I will not say that people might not do it anyway, but at what point do
>>> we say "you were warned"?
>>
>> OK, sounds good enough.
>
> I personally think it's a little strange for this to be configurable.
>
> I have a poor imagination and cannot imagine why it needs to be
> switchable.  If someone switches it to "a" does that mean that any
> commit message line that starts with the letter "a" will be filtered
> out?
>
> Specifically, core.commentchar seems really unnecessary to me.  What
> is the benefit?
>
> I do see downsides -- folks do parse the output, they don't read the
> release notes, they don't know any better, but, hey, "it works", so
> they'll be broken just because someone doesn't like "#"?
>
> What about hooks that write custom commit messages?  Do they need to
> start caring about core.commentchar?

They are valid questions, I think, but are best asked to those who
wanted core.commentchar configuration, not to people involved in
this thread.  Also unfortunately it is too late by two releases to
ask that question.