Re: [RFC/PATCH] builtin/blame: darken redundant line information

From: Stefan Beller <sbeller@google.com>
Date: Jun 13, 2017, 17:30 UTC
Message-ID: <CAGZ79kafV5aXd9SAOHHGOgsAdpuY=YV6yWoWSsuG9rncLYhphA@mail.gmail.com>
In-Reply-To: <xmqqo9tr7qkk.fsf@gitster.mtv.corp.google.com>

On Tue, Jun 13, 2017 at 10:19 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 28 quoted lines

> Stefan Beller <sbeller@google.com> writes:
>
>> Here is what currently happens:
>>
>>>
>>>          context
>>>         -B              dim  oldMoved
>>>         -B              dim  oldMoved
>>>         -B              highlight oldMovedAlternative
>>>         -A              highlight oldMovedAlternative
>>>         -A              dim  oldMoved
>>>         -A              dim  oldMoved
>>>          context
>>>         +A              dim  newMoved
>>>         +A              dim  newMoved
>>>         +A              highlight  newMovedAlternative
>>>         +B              highlight  newMovedAlternative
>>>         +B              dim  newMoved
>>>         +B              dim  newMoved
>>>          context
>>>
>>
>> So the there is only one "highlight" color in each block.
>> There is no separate hightligh-for-ending-block and
>> highlight-for-new-block respectively.
>
> I think the adjacentbounds mode is simply broken if that is the
> design.

ok. Going by this reasoning, would you claim that allbounds would also be broken design:

Show 16 quoted lines

> git show --color-moved=allbounds:
>          context
>         -B              oldMovedAlternative
>         -B              oldMoved
>         -B              oldMovedAlternative
>         -A              oldMovedAlternative
>         -A              oldMoved
>         -A              oldMovedAlternative
>          context
>         +A              newMovedAlternative
>         +A              newMoved
>         +A              newMovedAlternative
>         +B              newMovedAlternative
>         +B              newMoved
>         +B              newMovedAlternative
>          context

>
> In the above simplified case, you can get away with only a single
> "highlight" color, but you cannot tell where the boundaries are when
> three or more lines are shuffled, no?

But you do not want to (yet)? The goal is not to tell you where the bounds are, but the goal is to point out that extra care is required for review of these particular 3 lines.

So IMHO this feature helps for drawing reviewer attention, but not for explaining blocks.

In an extreme alternative design, we would have just annotated each hunk in the context lines for example telling that there are n out of m new lines. But that information by itself is not useful for review

Instead this alternative moved line detection could have an impact on diff stats.