Re: [PATCH] diff.c: color moved lines differently
- From
Stefan Beller <sbeller@google.com>
- Date
- Jun 14, 2017, 18:55 UTC
- Message-ID
- <CAGZ79kaqjQYmkt77kk5m=fdBfbZAvwd0YhhT7=O5b-FkQmDfHg@mail.gmail.com>
- In-Reply-To
- <20170613155158.2454d9c7@twelve2.svl.corp.google.com>
On Tue, Jun 13, 2017 at 3:51 PM, Jonathan Tan <jonathantanmy@google.com> wrote:
Show 21 quoted lines
> On Wed, 31 May 2017 17:24:29 -0700 > Stefan Beller <sbeller@google.com> 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)