On Tue, Jun 13, 2017 at 10:19 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> 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: > 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.