You know that scenario, it happened to you a thousand times :
What are ways of mitigating this? The only solution I found so far is self-discipline: Enforce commits containing ONLY the file moving and renaming. Zero modification allowed. Leave that for a subsequent commit. Even better : Do the move/rename in an entirely separate PR (so that the actual changes are still easily visible in the "all changes" view of gitlab or other tools)
The difficulty with that approach is that it adds some overhead. Another problem is reluctant devs who don't want to comply to that or forget to do it, because they can't see that it was much easier for them to see the changes in a moved file at the time they committed than for the reviewer reading the final result.
Do you know of any other way?
yes you are right its either being deciplined or working with built in UI in your editor but if you find your self in a such situation then i hope this helps :
git config --global diff.renames true
git config --global diff.renameLimit 999999
Show the diff of a moved file, ignoring the move itself
git diff --color-moved=blocks --find-renames
git log -M -C --stat --follow path/to/file
git show --color-moved=blocks commit_hash
git diff --color-moved=blocks HEAD^..HEAD path/to/new/file
git diff --find-renames=90% --break-rewrites
git format-patch --find-renames --break-rewrites HEAD^
git diff branch1...branch2 --color-moved=blocks --find-renames