W dniu 2016-07-01 o 20:01, Junio C Hamano pisze:
> Michael Haggerty writes:
>> It often fails to get C preprocessor directives right:
>>
>>> a08595f76159b09d57553e37a5123f1091bb13e7:http.c
>>> aeff8a61216bf6e0d663c08c583bc8552fa3c344:http.c + 429
>>> v
Michael Haggerty writes:
> I put quite of work into tooling to evaluate diff heuristics, and just
> published it on GitHub:
>
> https://github.com/mhagger/diff-slider-tools
>
> The README there is hopefully enough to let people get started using it
> to test their own favorite heuristics.
In
On 06/23/2016 07:10 PM, Michael Haggerty wrote:
> On 06/17/2016 06:09 PM, Stefan Beller wrote:
>> I think before spending more time on discussing and implementing new
>> (hopefully better) heuristics, I'd want to step back and try to be a bit more
>> systematic, i.e. I'll want to collect lots of te
On 06/23/2016 07:37 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Scoring heuristic:
>>
>>> # A place to accumulate bonus factors (positive makes this
>>> # index more favored):
>>> bonus = 0
>>>
>>> # Bonuses based on the location of blank lines:
>>> if pre_blank
Michael Haggerty writes:
> Scoring heuristic:
>
>> # A place to accumulate bonus factors (positive makes this
>> # index more favored):
>> bonus = 0
>>
>> # Bonuses based on the location of blank lines:
>> if pre_blank and not blank:
>> bonus += 3
>> elif blank an
On Thu, Jun 23, 2016 at 10:10 AM, Michael Haggerty wrote:
> On 06/17/2016 06:09 PM, Stefan Beller wrote:
>> I think before spending more time on discussing and implementing new
>> (hopefully better) heuristics, I'd want to step back and try to be a bit more
>> systematic, i.e. I'll want to collect
On 06/17/2016 06:09 PM, Stefan Beller wrote:
> I think before spending more time on discussing and implementing new
> (hopefully better) heuristics, I'd want to step back and try to be a bit more
> systematic, i.e. I'll want to collect lots of test cases in different
> languages
> and use cases. A
On Fri, Jun 17, 2016 at 8:36 AM, Jeff King wrote:
>
> Did you want something that triggers the "bad" case with the existing
> compaction heuristic?
>
> I gave one in:
>
> http://article.gmane.org/gmane.comp.version-control.git/296947
I found that out after sending the initial patch. Thanks for
On Thu, Jun 16, 2016 at 10:46:20AM -0700, Stefan Beller wrote:
> The compaction heuristic for diffs was deemed quite good, but in 5580b27
> we have an example demonstrates a common case, that fails with the existing
> heuristic. That is why we disabled the heuristic in the v2.9.0 release.
>
> Wit
>
> The heuristic I proposed was
>
> * Prefer to start and end hunks *following* lines with the least
> indentation.
>
> * Define the "indentation" of a blank line to be the indentation of
> the previous non-blank line minus epsilon.
>
> * In the case of a tie, prefer to slide the hunk down as
On 06/16/2016 07:46 PM, Stefan Beller wrote:
> The compaction heuristic for diffs was deemed quite good, but in 5580b27
> we have an example demonstrates a common case, that fails with the existing
> heuristic. That is why we disabled the heuristic in the v2.9.0 release.
>
> With this patch a diff
On Thu, Jun 16, 2016 at 1:27 PM, Junio C Hamano wrote:
>> ...
>> because there is less space between line start and {end, def bal}
>> than for {do_bal_stuff, common_ending}.
>
> I haven't thought this carefully yet, but would this equally work
> well for Python, where it does not have the "end" or
Stefan Beller writes:
> +def bal
> +do_bal_stuff()
> +
> +common_ending()
> +end
> +
> def baz
> do_baz_stuff()
>
> common_ending()
> end
>
> whereas before we had:
>
> WIP (TODO: ask peff to pro
The compaction heuristic for diffs was deemed quite good, but in 5580b27
we have an example demonstrates a common case, that fails with the existing
heuristic. That is why we disabled the heuristic in the v2.9.0 release.
With this patch a diff looks like:
def bar
do_bar_
14 matches
Mail list logo
