Git Merge and Fixing Mixed Spaces and Tabs with two Branches

Question

I've gone through some similar SOQ's and have not seen an adequate solution for this case.

I've noticed that in many files there is a dirty mix of tabs and spaces used for indenting. The coding standard we follow uses 4 spaces for a tab currently.

Although this should have been addressed when it happened, I need to consider it now and would like to fix the files I come across. The issue is that there are two teams using different branches of code and we will eventually have to merge those branches. What will happen if we change all the files of our branch to be the correct formatting and try to merge it? Will it end up being difficult to do so? Will it show me a ton of conflicts? Ideally id like git merge to ignore whitespace but I dont know how it would know which version to choose.

Are there better solutions from a reactive point of a view?

This is primarily a tech leadership, code lint, code review issue, yet I am not in that position or case currently. Can I fix this easily? (Having the offenders handle the merge is out of the question unfortunately!)

Britain

Is this not sufficient? #4861803 – Monticule

didnt see that one, and it leads to what I choose as an answer below. – Britain

The response here is much more complete tought – Galbanum

Possible duplicate of git whitespace woes – Valer

Answer 1

By default git will see each difference in a line's indentation as a change, so yes you're likely to end up with mass conflicts doing a stock merge.

However you can choose the merge strategy to use with the -s option:

git merge -s recursive -Xignore-space-change

This command would use the recursive strategy and uses it's ignore-space-change option. The git-merge docs explain quite well how this will affect your merge:

• 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

It would also be prudent to look at what git thinks has changed before doing the merge using diff with some extra options. Looking through the diff docs it looks like these options would help you out the most:

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

-w
--ignore-all-space Ignore whitespace when comparing lines. This ignores differences even if one line has whitespace where the other line has none.

Groceryman

Answer 2

Why not run both code bases through indent with a the same style on both branches? Doesn't take long.

Then you won't have any whitespace or other issues (like different block styles). Otherwise, yes, it will be hard to merge those branches.

Assuming you code in C, obviously.

Unchancy

I though git merges looks through the history of both branch, and applies each change until it reaches the common commit. Your solution assumes git merges only looking at the end-results of both branches. Is this the case? – Kemme

I think that @Kemme is right and that such merge would fail. – Rufena

It won't work when you e.g. wrap a block of code into an if statement, which increases indent of the block. – Extended

Answer 3

Assuming you have at least three branches (say 'master', 'team1', 'team2') then update the 'master' branch with all of the correct spacing/indenting and have each team pull in the changes from 'master'. Each team should then ensure all of their new code/files meet your standard coding practice.

Insignia

Answer 4

Note that, as mentioned in "Git: Merging without whitespace conflicts", using git merge -Xignore-space-change will

• ignore all whitespace changes in the file, not just whitespace where there are conflicts,
• however, the resulting merged file get the whitespaces back,
• using a pre-commit hook in addition of that merge strategy can help remove completely those trailing whitespaces.

Trinia