Re: [RFC PATCH, WAS: "weird diff output?" 0/2] implement better chunk heuristics
- From
Jacob Keller <jacob.keller@gmail.com>
- Date
- Apr 15, 2016, 19:09 UTC
- Message-ID
- <CA+P7+xpr1nVhKpMCPdUdd8nTJ5aj+Mcxr0ML2Qz4PRqwoerK=Q@mail.gmail.com>
- In-Reply-To
- <CAGZ79kZPsGuimv3pFAFdwuhD1ps74qx7Q6d1kqxxRX6VPwNYGQ@mail.gmail.com>
On Fri, Apr 15, 2016 at 10:33 AM, Stefan Beller <sbeller@google.com> wrote:
Show 25 quoted lines
> On Fri, Apr 15, 2016 at 10:27 AM, Junio C Hamano <gitster@pobox.com> wrote: >> Stefan Beller <sbeller@google.com> writes: >> >>> Actually we would only need to have the empty line count in the >>> second loop as the first loop shifted it as much up(backwards) as >>> possible, such that the hunk sits on one end of the movable >>> range. The second loop would iterate over the whole range, so that >>> would be the only place needed to count. >> >> The description makes me wonder if we can do without two loops ;-) > > I think the existing 2 loops are needed to move "as much as possible" > to either boundary to see if there is overlap to another group and combine > the groups if so. (This whole construction prior to these patches remind > me of shaker sort) > >> >> That is, can we teach the first loop not to be so aggressive to >> shift "as much as possible" but notice there is an empty line we >> would want to treat specially? > > I think we need to be aggressive to find adjacent groups and only after > that is done we should think about optimizing look&feel? That is why I > even proposed to not touch the current 2 loops at all and have our own > loop to find out if there is at least one empty line.
Agreed, we need the two loops in order to aggressively merge all the changes together first.
Thanks, Jake