Re: Trouble merging line-numbers branch into master

[Eli Zaretskii <eliz@gnu.org>]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Fri, 07 Jul 2017 21:46:44 +0000
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> On Fri, Jul 7, 2017 at 5:41 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
>  Presumably the lines in question were changed in one branch or the other (not
>  necessarily by messing with white space), and our git settings are suggesting
>  that you omit the spaces before tabs while you're futzing with those lines.
> 
>  As build-aux/git-hooks/pre-commit suggests, you can work around the problem
>  temporarily with the shell command 'git config core.whitespace -trailing-space'.
>  I don't recommend this setting in general, though.
> 
> I found the error useful. So when line-numbers branch is eventually merged, instead of ignoring/bypassing this
> error, I'd suggest that that tab+space+tab combo be fixed and that whole thing be made to contain only tabs
> or only spaces (my preference). 

I've just merged the branch, and didn't have any such problems.  In
the diffs I see no changes due to whitespace only, and the only merge
conflict I had, in NEWS, had nothing to do with whitespace and was
resolved without introducing any whitespace.

So I really don't understand what is this all about.  If SPC followed
by a TAB is detected when you merge, it was already there in master
before the merge, and the merge itself is not the problem.

In any case, if someone bumps into this issue, please do NOT fix
whitespace as part of very large commits (such as the one I just did),
because in such jumbo changesets it's very important to be able to
identify real changes, and too many whitespace changes get in the way.

> Slowly and gradually, as more merges and commits happen in future, all such mixtures of tabs+spaces will
> get removed.

They cannot be removed completely, because indentation doesn't always
end in a column whose number is an integral multiple of the tab width.