David Aguilar <dav...@gmail.com> writes:
> On Wed, Aug 28, 2013 at 2:39 PM, Junio C Hamano <gits...@pobox.com> wrote:
>> Jeff King <p...@peff.net> 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
> 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.
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