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!)
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.
Merging Branches in a Local Repository To merge branches locally, use git checkout to switch to the branch you want to merge into. This branch is typically the main branch. Next, use git merge and specify the name of the other branch to bring into this branch.
No, merging does only affect one branch.
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.
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.
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