David Aguilar <davvid@xxxxxxxxx> writes: > 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? 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html