On Tue, Jun 13, 2017 at 3:51 PM, Jonathan Tan <jonathantanmy@xxxxxxxxxx> wrote: > On Wed, 31 May 2017 17:24:29 -0700 > Stefan Beller <sbeller@xxxxxxxxxx> wrote: > >> When a patch consists mostly of moving blocks of code around, it can >> be quite tedious to ensure that the blocks are moved verbatim, and not >> undesirably modified in the move. To that end, color blocks that are >> moved within the same patch differently. For example (OM, del, add, >> and NM are different colors): > > [snip] > > Junio asks "are we happy with these changes" [1] and my answer is, in > general, yes - this seems like a very useful feature to have, and I'm OK > with the current design. > > I do feel a bit of unease at how the emitted strings are collected > without many guarantees as to their contents (e.g. whether they are full > lines or even whether they originate from the text of a file), but this > is already true for the existing code. The potential danger is that we > are now relying more on the format of these strings, but we don't plan > to do anything other than to color them, so this seems fine. I will add comments into the code for that. > > I would also prefer if there was only one coloring method, to ease > testing, but I can tolerate the current multiplicity of options. I *think* by now everyone involved in the discussion agrees that we want Zebra + optional aggressive dimming (inside blocks as well as at bounds that are not adjacent to other blocks, i.e. anything non-adjacent to a different block)
