Re: A case where diff.colorMoved=plain is more sensible than diff.colorMoved=zebra & others

> On Thu, Dec 6, 2018 at 6:58 AM Phillip Wood <phillip.wood@talktalk.net> wrote:
> 
>>> So is there some "must be at least two consecutive lines" condition for
>>> not-plain, or is something else going on here?
>>
>> To be considered a block has to have 20 alphanumeric characters - see
>> commit f0b8fb6e59 ("diff: define block by number of alphanumeric chars",
>> 2017-08-15). This stops things like random '}' lines being marked as
>> moved on their own.
> 
> This is spot on.
> 
> All but the "plain" mode use the concept of "blocks" of code
> (there is even one mode called "blocks", which adds to the confusion).
> 
>> It might be better to use some kind of frequency
>> information (a bit like python's difflib junk parameter) instead so that
>> (fairly) unique short lines also get marked properly.
> 
> Yes that is what I was initially thinking about. However to have good
> information, you'd need to index a whole lot (the whole repository,
> i.e. all text blobs in existence?) to get an accurate picture of frequency
> information, which I'd prefer to call entropy as I come from a background
> familiar with https://en.wikipedia.org/wiki/Information_theory, I am not
> sure where 'frequency information' comes from -- it sounds like the
> same concept.
> 
> Of course it is too expensive to run an operation O(repository size)
> just for this diff, so maybe we could get away with some smaller
> corpus to build up this information on what is sufficient for coloring.
> 
> When only looking at the given diff, I would imagine that each line
> would not carry a whole lot of information as its characters occur
> rather frequently compared to the rest of the diff.