On Fri, Apr 15, 2016 at 2:15 PM, Jacob Keller <jacob.kel...@gmail.com> wrote: > On Fri, Apr 15, 2016 at 1:30 PM, Junio C Hamano <gits...@pobox.com> wrote: >> Jacob Keller <jacob.kel...@gmail.com> writes: >> >>> On Fri, Apr 15, 2016 at 1:06 PM, Junio C Hamano <gits...@pobox.com> 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.
What are your thoughts on adding this do the gitattributes diff section? Ie: modifications to the diff driver. Thanks, Jake -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
