Re: [PATCH 5/6] diff.c: omit uninteresting moved lines

> Stefan Beller <sbeller@google.com> writes:
>
>> It is useful to have moved lines colored, but there are annoying corner
>> cases, such as a single line moved, that is very common. For example
>> in a typical patch of C code, we have closing braces that end statement
>> blocks or functions.
>>
>> While it is technically true that these lines are moved as they show up
>> elsewhere, it is harmful for the review as the reviewers attention is
>> drawn to such a minor side annoyance.
>>
>> One of the first solutions considered, started off by these hypothesis':
>
> Hypotheses is the plural form of that word, I think.
>
>>   (a) The more blocks of the same code we have, the less interesting it is.
>>   (b) The shorter a block of moved code is the less need of markup there
>>       is for review.
>>
>>       Introduce a heuristic which drops any potential moved blocks if their
>>       length is shorter than the number of potential moved blocks.
>>
>>       This heuristic was chosen as it is agnostic of the content (in other
>>       languages or contents to manage, we may have longer lines, e.g. in
>>       shell the closing of a condition is already 2 characters. Thinking
>>       about Latex documents tracked in Git, there can also be some
>>       boilerplate code with lots of characters) while taking both
>>       hypothesis' into account. An alternative considered was the number
>>       of non-whitespace characters in a line for example.
>
> It was puzzling what the above two paragraphs were.  I took (a) and
> (b) were the hypotheses, and the two above, and also the next
> paragraphs, were the design that fell out of them.  But that is not
> what is happening.  You changed your mind and settled on the design
> in the next paragraph.