Since GitHub does not show diffs with the equivalent of `--ignore-space-change`, it is a good practice to avoid changing the indentation of large existing blocks of code, even when you change the logical nesting depth: it is much easier to review a diff that clearly just adds an alternative block of code and leaves the existing code untouched, than one that looks to rewrite a lot of complex stuff.

Other Git commands like  `merge`, `blame`, and `cherry-pick` treat whitespace changes as significant AFAIK, so the operation of these is also impaired by reindenting blocks. For example, if one commit indents a 100-line section by four spaces but otherwise does not touch it, and then a later commit makes a one-line change inside that section, and then an LTS maintainer tries to backport the second fix to a branch rooted before the first fix, it will be a merge conflict.