Photo by Daniele Levis Pelusi on Unsplash

Git-Config: diff.colormovedws

A Change in Indentation Isn’t a Change in Content

https://pragprog.com/newsletter/

In the last post, we looked at tricking out git diff to display moved lines differently from added and deleted lines. There’s a semi-predictable limitation to the diff.colormoved option, though. Changes to indentation will cause an otherwise unchanged, moved line to diff out as added and removed:

Nothing about the lines has changed except the indentation.

That’s unfortunate—especially because code moved as part of refactoring often must be indented or outdented differently to keep your codebase readable and organized.

There’s a fix for this issue: setting the diff.colormovedws configuration variable to allow-indentation-change will cause git diff to ignore any indentation changes at the beginning of lines:

$ git config --global diff.colormovedws "allow-indentation-change"

Re-running git diff on the example above, we can see that the moved lines are colored correctly, despite the change of indentation:

Lines whose content changes, but not indentation, are now easier to spot.

Configuring Git to Highlight Problem Whitespace

Photo by Milad Fakurian on Unsplash

The limitation to diff.colormovedws is that it is agnostic regarding leading whitespace characters, whether tabs or spaces. To ensure that all lines, moved or otherwise, adhere to the correct indentation character for your projects, you can configure Git's core.whitespace variable.

The core.whitespace variable is typically set to a subset of six common values, all of which represent errors — not preferences. Here are three values that address trailing spaces:

• blank-at-eof highlights any blank lines at the end of the file (EOF)
• blank-at-eol highlights end-of-line (EOL) spaces as an error
• trailing-space is a shorthand value for both blank-at-eof and blank-at-eol

Both blank-at-eof and blank-at-eol are enabled in Git by default, meaning that Git will always highlight trailing whitespace:

Trailing whitespace bleeds red on the screen.

The other three common values for core.whitespacee get into the sometimes contentious territory of indenting with tabs versus indenting with spaces:

• space-before-tab highlights any space characters appearing before tab characters on a line
• indent-with-non-tab highlights lines indented with spaces as an error, and it must be paired with a tabwidth value to accurately highlight errors
• tab-in-indenthighlights any tabs anywhere at the start of a line as an error

Note that space-before-tab is also enabled by default.

If you typically work on projects that require tabs instead of spaces for indentation, you’ll want to set core.whitespace like this:

$ git config --global core.whitespace "indent-with-non-tab,tabwidth=1"

Note the tabwidth=1 value, which has the side-effect of treating any number of leading space characters as errors. The default tabwidth on core.whitespace is eight characters, meaning that only eight spaces appearing in a row would be flagged as errors. Setting tabwidth to 1 will highlight any spaces in the indentation of a line:

If you’re Team Tabs, spaces highlight as indentation errors.

You can see that while the moved line’s content is still colored as moved, the offending space characters are highlighted in red. That’s again helpful for distinguishing indentation errors from truly changed lines.

Conversely, if you work on projects whose lines are indented with spaces, you’ll want to set core.whitespace like this:

$ git config --global core.whitespace "-space-before-tab,tab-in-indent"

The -space-before-tab value, with the leading -, turns off the default space-before-tab setting. The file, now indented with tabs, shows the tabs as errors:

Members of Team Spaces delight in highlighting tabs as indentation errors.

Of course, you might well do development across different languages and projects that have competing indentation rules. In the next post, we’ll look at how to configure Git at different levels of scope, so that you’re always working with a set of configuration values that match the conventions for the project you’re working on.

Karl Stolley

Karl’s book, Programming WebRTC: Build Real-Time Streaming Applications for the Web, is available in beta from The Pragmatic Bookshelf. You can save 35 percent with promo code git_config_2022 now through August 30, 2022. Promo codes are not valid on prior purchases.

Programming WebRTC