I strongly and broadly disagree, both with the premise and the argumentation they do.

But first off, and because it’s significant to the argumentation; Why is their entire argumentation in line-based diffs, but when I go to their homepage I see screenshots of inline diffs?

Inline-marking of differences are incredibly powerful. Programming language aware diffing should make use of understanding to support the highlighting, with the option to ignore different levels of irrelevance at the users choice.

I don’t want anything hidden. I want to default to every difference shown, but put side by side as much as possible, with different levels of highlighting of the differences according to their relevance and significance.

I want to default to every difference shown, but have alternative options to ignore things. I want to have the option to ignore whitespace changes, and potentially additional options to ignore more (this is the opportunity semantic understanding could bring, in addition to the line and change matching).

TortoiseGitMerge allows me to choose between

• Compare whitespace
• Ignore whitespace changes
• Ignore all whitespace changes

I default to the first, but regularly switch to the second and third, when indents change. They are irrelevant when assessing the logical changes. But whitespace is still significant in laying out code. It’s both significant, but for different reasons, and as different layers and layers of assessment.

All that being said, we don’t use an enforced automatic formatter.

But also, we use whitespace, line breaks, and other syntax consciously. Readability takes precedence over consistency. I hate hard character limits on lines. Sometimes the vertical structure is much more significant to readability than an arbitrary (and often narrow) line character limit.

One example:

Do you write

if (error != null) return error;

or do you write

if (error != null)
    return error;

or do you write

if (error != null)
{
    return error;
}

I dislike the second because its semantic structure not very obvious and somewhat error prone. For simple early returns like this, I prefer the first. But in cases where it’s not a simple and short return, the third can be preferable despite being only one statement.

Automated formatters often can’t do one or the other alternatively, and sometimes don’t allow ignoring one rule.