Phillip Wood <phillip.wood@xxxxxxxxxxxx> writes: > The code actually looks at the lines that are selected rather than > omitted. So in the example above it groups them as [1,2] (because they > are contiguous), [4],[5] (these are split because one is an insertion > and one a deletion) and [7]. It then sees that there are two groups of > deletions ([1,2],[4]) and two groups of insertions ([5],[7]) and so > pairs up the deletions in [12] with the insertion in [5] and likewise > with [4] and [7]. Lines 3 and 6 are never explicitly paired, although > they basically behave as if they were. One the insertions are all paired > up it walks over the list and creates a new hunk where the paired > insertions come immediately after their corresponding deletions, > unselected deletions are converted to context lines and unselected > additions are dropped. Now, without that much explanation in help text, can an average end user use the feature, specifically, understand the reason why the tool says it cannot handle a particular set of selected lines, and follow the workaround suggested by the tool to do it in two (or more) batches? That was the real question I was getting at. I haven't played with the feature long enough to answer that question. >>> Reported-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> >> >> Is this fixing any bug? I usually see "Reported-by" only for a >> bugfix patch but this seems to be adding a new feature (and lack of >> feature is usually not a bug). > > I guess I meant that the previous series was effectively buggy as it > would give the wrong result for modified lines. I wanted to acknowledge > that Ævar spent some time testing it and pointed that out. Ah, I see. We generally throw these into "Helped-by", I'd think. Thanks.
