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