Re: What's cooking in git.git (Jun 2017, #03; Mon, 5)

On Wed, Jun 7, 2017 at 10:41 PM, Jacob Keller <jacob.keller@gmail.com> wrote:

https://public-inbox.org/git/20170613023151.9688-1-sbeller@google.com/ restarted the discussion on this feature, so I assembled a team of color experts (my office mates), and we came to this conclusion more or less:

There are different ways to implement a move detection. Different
  people prefer different things, the main contenders are:

1)    "Zebra mode" (in the last patch known as "alternate" mode.

    This alternates between 2 colors for blocks of moved code.
    This may or may not reset to the first color, but the main features are:
    a) the whole block is in one color
    b) adjacent blocks have different colors.

For this implementation we need 4 new colors (2 colors for +, 2 for -)

2)    "Highlight bounds + dimming in between"

    A block is generally in a dim color. Depending on further configuration
    the boundaries are highlighted. There are different modes for that:
    a) all boundaries are highlighted
    b) bounds adjacent to other moved blocks of same sign are highlighted
    c) no bounds highlighted, moved code is only dimmed.
        (sucks for seeing blocks)
    d) [NEW] only the first (last) border line.
        This is consistent with the thread that started the discussion as
        this is done in the RFC for blame.

  The configured colors "oldMoved" and "oldMovedAlternative"
  are assumed that one is highlighting and the other is the dim color.

  Depending on the exact implementation we'd need up to 6 new
  colors (dim, highlight, highlight alternative for each + and -)
  The user may configure these to be the same though, e.g.
  both dims could be 'context'.

3) Combine 1) and 2)

    The algorithm would look like this:
    a) Find moved blocks
    b) Take one option from 2) to highlight the bounds. (all bounds
      or adjacent bounds are the only serious contenders IMHO)

  This needs 8 new colors configured:
  for each of (new, old):
    for each of (Zebra black, Zebra white):
      for each of (dim, highlight):
        define_color()

The color experts agreed that (3) might be the best solution as this gives most flexibility:

    "I would be happy as I can configure the bounds highlighting
    to not exist, it would degenerate to a pure Zebra, which is
    very simple to understand. Junio seemed to like (2) a lot, so
    he would configure both dim colors to be 'context', but configure
    the highlight colors to be attention drawing. So everybody would
    be happy. It is also not too many colors, we are good at for loops."

I hope to have summarized this adequately.

Thanks, Stefan