On Fri, Dec 16, 2011 at 11:33:30AM -0800, Junio C Hamano wrote: > I think we recently saw that the optional built-in one for C did not even > understand a function that returns a pointer, and nobody complained about > it for a long time, Yeah. That implies to me that either people don't really care about this feature, or that they are not actually using it because it requires special configuration (we are not even using it in git.git, for example). > > And if it is bad on balance, is the right solution to avoid exposing > > people to it, or is it to make our patterns better? > > Can't we do both, by avoid exposing normal users to broken one while > people who want to improve the pattern based one work on unbreak it? Sure, we can do both. But if nobody is eating the dogfood, it will never grow to taste better. Maybe we should start by using diff=c in git itself? > > I.e., is it fixable, > > or is it simply too hard a problem to get right in the general case, and > > we shouldn't turn it on by default? > > I do not think that is the "either-or" question. My impression has been > that even if it is fixable, it is too broken and produces worse result > than the simple default in its current form. What I meant by the either-or was: if it is fixable, then we should fix it and consider turning it on as a default. If it's too hard to get right, then we probably never want it on by default, and people who do like it can turn it on (presumably because it works on their code style). -Peff -- 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