Re: [PATCH] attr: map builtin userdiff drivers to well-known extensions

From: Jeff King <peff@peff.net>
Date: Dec 17, 2011, 01:17 UTC
Message-ID: <20111217011751.GA20225@sigill.intra.peff.net>
In-Reply-To: <7vehw4ia5x.fsf@alter.siamese.dyndns.org>

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).

Show 5 quoted lines

> > 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?

Show 7 quoted lines

> > 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