On Fri, Apr 15, 2016 at 10:27 AM, Junio C Hamano <gits...@pobox.com> wrote: > Stefan Beller <sbel...@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. -- 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
