Colormoved: why are whitespaces sometimes flagged as "added" and not "moved" ?

[bro69noscope]

• My issue:

I think we can kind of agree that aesthetics wise, if we conceive of this picture has having 3 "blocks" they look like this:
(this formatted block is probably only understandable on dekstop)

                                                     1: UGLY
                                                     # has a weird mix of green and blue

2: UGLY
# has a weird mix of purple and red

                                                     3: LOOKS GOOD
                                                     # clean separation between blue and green              

Basically, it looks bad because the "moved" backgrounds (blue and purle in my case) are interrupted and return to the generic red/green "for some reason". And it feels pretty hard for me to actually understand what that "some reason" is 😅. There are no actualy whitespaces on the lines after the code moved, I'm just using that name cause I coulnd't think of another way to describe it. The lines seem to fail to be recognized as "fully moved lines" in BLOCK 1 and 2 but not 3 ?

Is there anything that delta accepts as a setting that would make BLOCK 1 and 2 look like 3 ? with a continuous background color ?

[ShreeChaturvedi]

This is git's move detection breaking, not delta. When a moved line's indentation changed (even by one space), git stops treating it as "moved" and falls back to normal add/remove colors. That's why blocks 1 and 2 have that red/green interruption while block 3 looks clean.

Add this to your .gitconfig:

[diff]
    colorMoved = default
    colorMovedWS = allow-indentation-change

colorMovedWS = allow-indentation-change tells git to keep treating lines as moved even when their indentation shifted. It groups them into the same moved block as long as every line in the block shifted by the same amount.

You can test it before committing to the config with git diff --color-moved-ws=allow-indentation-change.