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 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html