In few places its been mentioned that .pbxproj file should be committed/imported as binary in cvs or git. it looks like script file in text format. what are reasons behind this suggestion that it should be treated as binary?
As mentioned here, pbxproj is not really mergeable, being a complex property list managed as JSON.
The usual setting is in a .gitattributes:
*.pbxproj -crlf -diff -merge
As explained here:
This prevents Git from trying to fix newlines, show it in diffs, and excludes it from merges.
The other approach is:
*.pbxproj binary merge=union
As documented here, this didn't work well.
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.
Related
I would like a set of rules from my_package.bzl to be accessible to all BUILD files of a workspace without having to load my_package.bzl in the BUILD files. Basically I want the rules in the package to look like native rules. How can I achieve this?
I was thinking maybe there's a line I could add to one of the .bazelrcs or to the WORKSPACE file of the the project.
This can be achieved by adding a prelude_bazel file at //tools/build_rules:prelude_bazel (this must be a package, so tools/build_rules must contain a BUILD file).
This will be loaded and prepended to all BUILD files loaded by Bazel.
However, there are a few things to consider before going this route. It's currently undocumented, and while doing some searching to find any info on this feature, it's unclear if it will remain a part of Bazel.
It may also have performance / scaling problems. If the prelude were to change (or any of its dependencies), every BUILD file would have to be reloaded, and this may take some time depending on the size of the build graph.
Although I already read similar comments here, in this forum, I haven't found an approach that may be suitable for teamwork in a seamless way.
If you know what I mean, you already may found tricky working with git and the project.pbxproj file in Xcode, even when you are working in a different file.
Say,
A developer: created Foo folder, adding foo.swift to the project.
B developer: created Bar folder, adding bar.swift to the project.
Different paths... but you know, conflict! And as you may also noticed, leaving project.pbxproj out is not an option.
So my question is: How do you handle this in a professional manner, Git flow ready and easiest way.
Thank you all very much.
PS: I'm using currently Bitbucket and SourceTree if matters.
PS2: I'd like to avoid command line and manually file editing if possible.
Create a .gitattributes file and adding the following line:
*.pbxproj merge=union
Merges will happen automatically and without you having to touch anything.
Alternatively, you might try mergepbx, which does a more intelligent merge.
New files are created by only one developer on "main-develop" branch.
Push new files to "main-develop"
Those files are implemented by other developers after pull
I'm one of the maintainers of Kintsugi, a tool that intelligently merges the conflicts and promises to automatically solve 99.9% of the conflicts that occur in project.pbxproj files.
The readme also contains instructions on how to set it up as Git merge driver, so it will be applied automatically whenever a conflict in a *.pbxproj file occurs. I don't know of a way to do that from Sourcetree, but for most conflicts after setup you won't have to touch the command line again.
I used Atom to edit some PO translation files for the Neovim project, but when I saved the files, Atom changed a bunch of other lines (which I did not edit) in each file.
You can see the results in this commit. Basically each translation file has 5-10 other lines that git says are also changed.
I'm guessing there was some kind of encoding issue, can anyone provide a more detailed explanation?
Also, how do I edit these files without messing with the encoding?
Background: git -- or any other SCM -- can "successfully" merge Storyboards, xib's, and pbxproj files as at their core they are just xml. Sometimes there are conflicts which can be resolved by the usual conflict resolution strategies. But xib's and Storyboards are serialized formats of some pretty complex data structures, so the fun begins.
Just as with other source code, a successful merge doesn't guarantee all the merged changes work correctly together. With the files in question, git can successfully merge but Xcode sometimes displays a "Could not read archive" error when you try to open it - i.e., the merge corrupted the xib.
I've seen suggestions about having git ignore .xibs (not practical), or in .gitattributes disable diff by setting
*.xib -crlf -diff
Technically, that fixes the merge conflict/corrupted xib problem - but now somebody's changes are lost?
Similarly, the best recommendation I've seen for the project file is merge=union in .gitattributes:
*.pbxproj merge=union
Question: I've searched quite a bit and there doesn't seem to be a good solution. Can people with experience tell me what happens in a few use cases?
In the project I rename a file from x to y, and delete fileA. Meanwhile, another programmer committed changes to add fileC and delete fileD. What is the result of merge? I'm sure the actual file system changes will be correct, but in the Xcode navigator panel:
Will I see both x and Y?
Will fileA reappear because it's still in the other programmer's .pbxproj?
Will fileD still be there because it's still in my .pbxproj?
If git is ignoring .xib files - will I at least get a warning that a file was changed and is not being handled?
I wouldn't set any specific .gitattributes for project files or nibs these days.
Your problems merging concurrent changes to Xcode projects and xibs/storyboards exist in every team with more than one developer.
Xcode projects
A few tricks for dealing with Xcode project conflicts:
Take one side of the merge and manually apply the other changes after the merge. If you've deleted files they'll be in red, if you need to add them they'll be available to add.
When adding files to your targets they will go at the bottom of the 'Compile Sources' build phase. Avoid conflicts with other people by dragging them up this list to a random position.
Use .xcconfig files to configure your projects rather than the build settings section. Config files are trivial to merge.
My best advice if in doubt is to take one side of the merge, relax, and replay your additions.
XIBs and Storyboards
The format of XIBs (and therefor storyboards) has change significantly in recent months. I've found that additional objects are appended to the file's internal collections and merges can be done easily. If you're making changes to the same object, you may have to get in there manually.
This post from Itty Bitty Apps highlights the main changes:
The benefits of this new XIB XML format are many fold:
XIBs are much smaller (fewer lines of code).
A developer can easily read the XML and understand what it specifies in the user interface.
Merging XIBs is now much less likely to lead to broken XIBs. Before we would rarely even bother to try and merge a XIB or Storyboard.
I have been an iphone developer for a while, and I have recently been including git in my workflow. I have used git settings found on http://shanesbrain.net/2008/7/9/using-xcode-with-git for my workflow so far.
Those settings tell git to exclude *.pbxproj from merges? Is there a real reason for doing this? For example, when I add a file to the project and push to origin, my fellow developers will not have that file added to their xcode project when they pull. Then if one of them builds a release this file may not be included. Shouldn't I just let git handle the merges for the project file? Why or why not this file should be in merges and how to properly handle the situation when files are added to the project?
I have worked on iPhone applications full time since the SDK launch, most of that time spent working on teams with multiple developers.
The truth is that it's way more harmful to disallow merging of that .pbxproj file than it is helpful. As you say, when you add a file unless other people get that file, they have to also add it to their project - in an application of any size, that sucks and it also takes away a huge benefit of source code control in that you cannot really revert to a complete earlier project state just through git.
The .pbxproj file is simply a property list (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, which for git at least simply involves removing any >>>>, <<<<, and ==== lines. In fact this is so common that I have created a simple shell script to fix a .pbxproj file in a merge state from git, I run this from within the project directory (at the Classes level):
#!/bin/sh
projectfile=`find -d . -name 'project.pbxproj'`
projectdir=`echo *.xcodeproj`
projectfile="${projectdir}/project.pbxproj"
tempfile="${projectdir}/project.pbxproj.out"
savefile="${projectdir}/project.pbxproj.mergesave"
cat $projectfile | grep -v "<<<<<<< HEAD" | grep -v "=======" | grep -v "^>>>>>>> " > $tempfile
cp $projectfile $savefile
mv $tempfile $projectfile
Worst case if it fails (you ask XCode to load the project and it fails to load), you simply delete the .pbxproj file, check out the master from git, and re-add your files. But I've never had that happen in many months of use with this script, again working full time on iPhone applications with several other developers.
Another option (pointed out in comments below) that you can try using in place of the script, is to add this line to a .gitattributes file:
*.pbxproj text -crlf -diff -merge=union
Then git will always take both sides of a merge for the .pbxproject files, having the same effect as the script I provided only without any extra work.
Lastly, here is my complete .gitignore file, showing what I do have it set to ignore as there are a few things you don't want - in my case really just emacs remnants and the whole build directory:
# xcode noise
build/*
*.pbxuser
*.mode1v3
*~
# old skool
.svn
# osx noise
.DS_Store
profile
This works for me in Xcode 4.6 and Git 1.7.5.
Add and commit .gitattributes file with this:
*.pbxproj binary merge=union
I've tested this with another team member and works great.
Taken from:
http://robots.thoughtbot.com/post/33796217972/xcode-and-git-bridging-the-gap
Frankly, the existing answers are misleading.
If you never delete or rename files, then using the merge=union strategy, which just combines the differences in different commits directly, is a good idea.
However, in the real world, we do need to delete or rename files sometimes. Merging the differences without any modification would make a lot of problems under these situations, and these problems usually lead to the "Workspace Integrity - Couldn't load project" issue, which makes you even not able to run the project.
The best solution I got so far:
1) Design the project well and add all the needed files at the beginning, so you would seldom need to change the project.pbxproj.
2) Make your features tiny. Don't do too many things in a branch.
3) For any reason, if you need to modify the file structure and get conflicts in project.pbxproj, use your favorite text editor to solve them manually. As you make your tasks tiny, the conflicts might be easy to solve.
The short answer is that even if you don't include that line in .gitattributes, you may not be able to easily merge two modified versions of a .pbxproj. It's better for git to treat it as a binary.
See here for details: Git and pbxproj
Update: Even though the git book still agrees with this answer, I no longer do. I version control my .pbxproj just like any other non-binary source file.
I did create a Python script that can handle merge conflicts in XCode Project files.
If you want to try it, you can check it out here: https://github.com/simonwagner/mergepbx
You will have to install it as a merge driver, so it gets called automatically when you have a merge conflict in your project file (the README.md will tell you how to do that).
It should work much better than using merge=union as mergepbx understands the semantics of your project file and therefore will resolve the conflict correctly.
However the project is still alpha, don't expect it to understand every project file that is out there.