On Fri, Apr 15, 2016 at 10:33 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > On Fri, Apr 15, 2016 at 10:27 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Stefan Beller <sbeller@xxxxxxxxxx> 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 -- 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