If their version only introduces whitespace changes to a line, our version is used; If our version introduces whitespace changes but their version includes a substantial change, their version is used; Otherwise, the merge proceeds in the usual way.
git merge -Xignore-all-space
Or (more precise)
git merge -Xignore-space-change
should be enough to ignore all space related conflicts during the merge.
See git diff:
--ignore-space-change
Ignore changes in amount of whitespace.
This ignores whitespace at line end, and considers all other sequences of one or more whitespace characters to be equivalent.
--ignore-all-space
Ignore whitespace when comparing lines.
This ignores differences even if one line has whitespace where the other line has none.
ks1322
adds in the comments a good advice:
It is worth to merge with
--no-commit
and review the merge before actual commit.
The OP Callum Macrae reports that, in that case, the merge proceed uninterrupted, and the trailing spaces contained in the pull request patches are applied to the local files.
However, the OP uses a pre-commit hook which takes care of said trailing spaces.
(I suppose a bit similar to this one, also referenced here).
The OP's pre-commit hook is referenced here:
In addition to removing trailing whitespace, it removes one to three spaces before tabs (I have tab width set to 4), and adds EOLs.
I've had reports that the code that adds the EOL deletes the file in windows, but haven't been able to replicate it.
If you see that you have a lot of whitespace issues in a merge, you can simply abort it and do it again, this time with -Xignore-all-space or -Xignore-space-change. The first option ignores whitespace completely when comparing lines, the second treats sequences of one or more whitespace characters as equivalent.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With