Jacob Keller <jacob.keller@xxxxxxxxx> writes: > On Fri, Apr 15, 2016 at 1:06 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> I actually do not think these knobs should exist when the code is >> mature enough to be shipped to the end users. >> >> Use "diff.compactionHeuristics = <uint>" as an opaque set of bits to >> help the developers while they compare notes and reach consensus on >> a single tweak that they can agree on being good enough, and then >> remove that variable before the code hits 'next'. >> >> Thanks. > > I was under the impression that we would want a longer lived > configuration until we had enough data to say whether it was > helpful to make it default. I guess i had thought it would need to > be longer lived since there may be cases where it's not optimal > and being able to turn it off would be good? Once you start worrying about "some cases this may misbehave", a configuration variable is a wrong mechanism to do so anyway. You would need to tie this to attributes, so the users can say "use this heuristics for my C code, but do not apply it for my AsciiDoc input", etc. 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. -- 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