I'm wondering whether the merge=union option in .gitattributes makes sense for .pbxproj files.
The manpage states for this option:
Run 3-way file level merge for text files, but take lines from both versions, instead of leaving conflict markers. This tends to leave the added lines in the resulting file in random order and the user should verify the result.
Normally, this should be fine for 开发者_JS百科the 90% case of adding files to the project. Does anybody have experience with this?
Not a direct experience, but:
- This SO question really advices again merging
.pbxproj
files.
The
pbxproj
file isn't really human mergable.
While it is plain ASCII text, it's aform of JSON. Essentially you want to treat it as a binary file.
(hence a gitignore
solution)
Actually, Peter Hosey adds in the comment:
It's a property list, not JSON. Same ideas, different syntax.
- Yet, according to this question:
The truth is that it's way more harmful to disallow merging of that .pbxproj file than it is helpful.
The.pbxproj
file issimply JSON(similar to XML). From experience, just about the ONLY merge conflict you were ever get is if two people have added files at the same time. The solution in 99% of the merge conflict cases is to keep both sides of the merge.
So a merge 'union' (with a gitattributes
merge directive) makes sense, but do some test to see if it does the same thing than the script mentioned in the last question.
- See also this question for potential conflicts.
- See the Wikipedia article on Property List
I have been working with a large team lately and tried *.pbxproj merge=union
, but ultimately had to remove it.
The problem was that braces would become out of place on a regular basis, which made the files unreadable. It is true that tho does work most of the time - but fails maybe 1 out of 4 times.
We are back to using *.pbxproj -crlf -merge
for now. This seems to be the best solution that is workable for us.
精彩评论