Why does this series first add proc expand_tabs, only to remove its

use in this second step?  Shouldn't these two patches be squashed
into one, and explain why we want to use "apply_tab_size 1" here?

Because I received feedback on the first commit and realized the 
second solution is better. I didn't know you could squash the patches
ones the first one was reviewed. 
I generally don't like rewriting history, but I will be squashing the 
commits.
For some reason Johannes Sixt disappeared from the mailing list. 
I've never used such a clunky interface before. 
I guess linux users like self-flagellation.

It is clear that "apply_tab_size 0" is designed for a single-parent

diff, while "apply_tab_size 1" is designed for two parents diff. If
this new series to make sense, I think it should argue why that
setting that users are already familiar with for the past 14 years
is wrong, and "apply_tab_size 1" is more appropriate for a single
parent diff (and presumably "apply_tab_size 2" is better for two
aprent diff), I think.

The bug has been there for 14 years I guess. In gitk it works as 
expected.In git diff it works as expected when setting up the pager.
In git-gui it doesn't. The alignment is inconsistent with gitk.
For code review it's horrible.
Here is a link to 2 images that show the before and after:
https://github.com/git/git/pull/2179#issuecomment-3799576864

-- Chris