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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 28, 2013 at 2:39 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Jeff King <peff@xxxxxxxx> 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?

Curious,
-- 
David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]