220

I've got a problem, where a large commit which changes about a thousand lines of code, removing whitespace from the end of lines and removing spaces before tabs.

There are also about 50 pull requests for this project, in which all will get conflicts, when my commit is merged. Is there any way that git can be set up so that when merging future commits, it ignores conflicts where one of them is just a whitespace change?

Modifying git itself or using a third party tool isn't possible, but using a hook is fine.

AsthaUndefined
  • 1,111
  • 1
  • 11
  • 24
callumacrae
  • 8,185
  • 8
  • 32
  • 49

3 Answers3

298
 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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks! Will that ignore whitespace just where there are conflicts, or all whitespace changes in the file? – callumacrae Mar 20 '12 at 13:23
  • 2
    From my tests so far, it looks like it removes all whitespace changes in the file. However, I am now using the pre-commit hook to remove tailing whitespace so it isn't an issue. – callumacrae Mar 21 '12 at 12:19
  • @CallumMacrae: when you say "it removes all whitespace changes in the file", you mean that the result of the merge (resolved automatically because it is instructed to ignore space changes) is that the new format (the one where you removed all trailing spaces) is preserved? The patches, once applied, don't restore the trailing spaces? – VonC Mar 21 '12 at 12:23
  • It just ignores the whitespace changes in that file, so after merging the new commit the trailing whitespace is back. – callumacrae Mar 21 '12 at 12:26
  • @CallumMacrae: ok that makes sense. But I suppose your pre-commit hook immediately takes care of the problem, right? – VonC Mar 21 '12 at 12:31
  • Yep! I should probably share it… I'll find it in a bit – callumacrae Mar 21 '12 at 12:32
  • @CallumMacrae excellent. I have added those information to the answer for more visibility. – VonC Mar 21 '12 at 12:43
  • The one you linked to is very similar to mine (I think it's based on what I based mine on). https://gist.github.com/2141321 In addition to removing trailing whitespace, it removes one to three spaces before tabs (I have tab width set to 4), and adds EOLs. It isn't perfect as my knowledge of git-hooks isn't great, but most of it should work. I've had reports that the code that adds the EOL deletes the file in windows, but haven't been able to replicate it. – callumacrae Mar 21 '12 at 12:48
  • 1
    @CallumMacrae: ok, and thank you for the feedback. Again, I have added your link in the answer for more visibility. – VonC Mar 21 '12 at 12:55
  • What about whitespace changes inside of string literals? – Ken Dec 18 '13 at 21:43
  • @Ken the pre-commit hook script I renferenced in my answer (https://gist.github.com/callumacrae/2141321) shouldn't touch those (unless there are 3 space and a tab in a string literal. – VonC Dec 18 '13 at 22:03
  • 1
    ***`git merge -Xignore-space-change`*** - well, I can say for certain this [did not work...](https://github.com/weidai11/cryptopp/blob/f8091d9a156bbd9cd8aa7fa4bc7cda7a934ad64e/oids.h). The one piece of whitespace I was trying to remove remained. Git absolutely sucks. – jww Jan 14 '16 at 15:07
  • 1
    It is worth to merge with `--no-commit` and review the merge before actual commit. – ks1322 May 20 '16 at 15:34
  • @ks1322 Good point. I have included your comment in the answer for more visibility. – VonC May 20 '16 at 15:47
  • this tip has saved me so much aggravation. thank you! – mydoglixu Aug 03 '18 at 01:20
  • 1
    -Xignore-all-space seems to do nothing about whitespace and --ignore-space-change was not recognized as an option by git – Preza8 Aug 28 '19 at 13:10
  • @Preza8 Which version of Git are you using? And what command did you type? – VonC Aug 28 '19 at 14:39
  • @VonC Git version 2.21.0.windows.1 The command was git merge origin/master -Xignore-all-space – Preza8 Aug 28 '19 at 14:48
  • @Preza8 I just tried that command: `git merge origin/master -Xignore-all-space` works, but `--ignore-space-change` would indeed not be recognized. – VonC Aug 28 '19 at 14:51
  • @VonC Well for me, there were lots of files with the only difference of one more empty line at the end and this did not help me with that. I did not notice any difference with or without this parameter. – Preza8 Aug 28 '19 at 14:55
  • 1
    @Preza8 OK. Please post a separate question, with details (OS, Git version, shell used, ...) and a small example: that way, others can help. – VonC Aug 28 '19 at 14:57
  • 1
    @VonC Thank you for the effort but I am working on source closed code, so I would have to reconstruct the issue manually and I'm not that bothered. I think I'll just solve it with regex or something. – Preza8 Aug 28 '19 at 15:07
  • 1
    You don't know how this blown my mind. That could save days of merging. Especially in JSX/HTML environments. – Ahmed Mahmoud Aug 24 '20 at 06:29
  • -Xignore-all-space didn't work for me either. the command was recognized but it did nothing about the conflicts i was getting due to empty lines. – Riz Aug 31 '20 at 21:41
  • @Riz Strange. If you can reproduce the issue, that would be a good question on its own to ask here. – VonC Sep 01 '20 at 06:31
  • For me, `git merge otherbranch -Xignore-all-space` worked in the sense that it made the merge a little less horrible. Significantly, it did take care of the 250-line block of "changes" that contained one real change of two lines and 248 lines that probably had a few whitespace changes sprinkled through it. – fool4jesus Jul 16 '21 at 14:12
2

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.

Vaibhav
  • 21
  • 3
0

I like to use meld to merge involved conflicts and there is the option to set various filter options under Meld>Preferences>TextFilters.

Beat Scherrer
  • 187
  • 2
  • 14