On Fri, Apr 15, 2016 at 1:30 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. > I think this makes perfect sense to apply this as an attribute, however.. why isn't the current diff algorithm done this way? Thanks, Jake > 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