On Fri, Apr 15, 2016 at 2:44 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jacob Keller <jacob.keller@xxxxxxxxx> writes: > >>>> What you have is a pure developer support; aim to come up with "good >>>> enough" way, giving developers an easier way to experiment with, and >>>> remove it before the feature is shipped to the end user. >> >> What are your thoughts on adding this do the gitattributes diff >> section? Ie: modifications to the diff driver. > > I do try to foresee the future needs but I try to limit the forecast > to "just enough so that we won't waste engineering effort on a wrong > thing". "It may need to be turned off conditionally" suggests we > would want attributes added per path, and that is sufficient to make > me say "don't waste time on bikeshedding configuration variable > names, it will not be in the final product". > > We do not need yet to know what the final name of the attributes > are, or how exactly the bit to affect the low level mechanism will > be set by the attribute mechanism. I do not think this topic is > there yet, and it is a waste of engineering effort to prematurely > trying to make things too flexible and customizable, when the thing > that will eventually become flexible by conditionally enabled is not > even there yet. > > As long as the low-level thing has a knob, set of internal bits, to > enable and disable it, that is all that is necessary to know at this > point. > > Having said all that, I'd expect we'd compute the right bit to use > in the same place where we currently pick the custom textconv > driver, diff backend, etc., by consulting the attribute system > before running the diff. > > But again, I'd think it would be waste of time to think beyond that > at this point, identifying exactly at which line of which source > file the new code would go and what that new code would look like, > until we are ready to start integrating it. Ok, for now I'll leave this as is then. Thanks, Jake -- 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