I was looking at an open source Mac application, and they gave some suggested values for .gitignore. They were what I would expect...
However, they also suggested an entry into a .gitattributes file:
*.pbxproj -crlf -diff -merge
I'm not the most knowledgable in terms of git, so I was wondering - what exactly are the benefits of adding this line? What does do in particular? I've only seen this suggested in this one project, and if it was normal practice I would have expected to see it elsewhere right now. So I was curious about how it applies to the pbxproj file specifically.
The pbxproj file isn't really human mergable. While it is plain ASCII text, it's a form of JSON. Essentially you want to treat it as a binary file.
Here's what the individual flags do:
-crlf: don't use crlf <=> cr conversion
-diff: do not diff the file
-merge: do not attempt to merge the file
From the Pro Git book by Scott Chacon
Some files look like text files but
for all intents and purposes are to be
treated as binary data. For instance,
Xcode projects on the Mac contain a
file that ends in .pbxproj, which is
basically a JSON (plain text
javascript data format) dataset
written out to disk by the IDE that
records your build settings and so on.
Although it’s technically a text file,
because it’s all ASCII, you don’t want
to treat it as such because it’s
really a lightweight database — you
can’t merge the contents if two people
changed it, and diffs generally aren’t
helpful. The file is meant to be
consumed by a machine. In essence, you
want to treat it like a binary file.
A diff is oftentimes useful at commit time to check what has been changed. So I find it useful to keep the diffing ability but just prevent merging. So I use this in my .gitattributes file:
*.pbxproj -crlf -merge
On another note, has anybody tried using merge=union for pbxproj files? See: Should I merge .pbxproj files with git using merge=union?
I faced the problem of corruption *.pbxproj file after resolving merge conflicts manually. Or, more often, my files just 'disappeared' from the working tree after the merge. It drove me mad because we work in a team, so you can imagine how messy it can become very fast.
So, I have tested merge=union and it works well so far. I know that it can't help if files were deleted or renamed at the same time, but for adding new files it works as expected: there is no conflicts and files don't disappear after the merge. And it also saves quite a bit of time.
If you want to try it out, here is what I did.
1) Create a global .gitattributes file. Run in terminal:
touch ~/.gitattributes
git config --global core.attributesfile ~/.gitattributes
2) This command should open it in a text editor:
open ~/.gitattributes
3) When the file opens, add this line and save the file:
*.pbxproj binary merge=union
Done. Hope this will help new readers like it helped me.
I wrote a python script named xUnique to solve this merge conflicts problem.
This script do following things:
replace all 24 chars UUID to project-wide unique 32 chars MD5 digests, and remove any unused UUIDs(usually caused by careless merge before). This would prevent duplicate UUIDs because different machines/Xcode generate different UUIDs in this file. Xcode does recognize it and the project could be opened. During this process, remove all invalid lines in project file
sort the project file. I wrote a python version of sort-Xcode-project-file from Webkit team with more new features:
support to sort PBXFileReference and PBXBuildFile sections
remove duplicated files/refs
avoid creating new file even if no changes made, this makes less commits after using this script
More details and updates of xUnique, please refer to README
Related
I have a .strings file that git interprets as binary by default, but I want everyone on my team to see the diff on GitLab when I create a pull request.
As per documentation, I'm able to see the diff locally when I add *.strings diff=Localizable to .gitattributes and this textconv driver to .git/config:
[diff "Localizable"]
textconv = "iconv -f utf-16 -t utf-8"
binary = false
The problem is, we don't commit the .git/config file, so everyone would have to add this to their config file and we still wouldn't be able to see the diff while reviewing code on GitLab. Is there a way to define textconv in a file that's safe to commit? I tried adding it to .gitattributes instead but it did nothing.
In case it matters, this is an Xcode project.
No.
This is unfortunate, but it's also necessary for security, because if you could define a textconv filter in a file that did get committed, a bad actor could define a fake filter that (while maybe doing some textconv-ing) acted as a Trojan horse, for instance.
What you can do is provide a script that sets this up for users, and tell them inspect the script if you like, and then if you trust it, run it to set things up. (Make the script as simple as you can so that people can inspect it first, though you might want to have it look to see if it's already been run and not do anything in that case.)
As torek mentioned, specifying textconv is not practical for security reasons. The best that you might be able to do is add a .gitattributes file in the root of your repository that declares this as text (like *.strings text=true) rather than binary. This should at least help you see the diffs in GitLab.
You need to commit your .gitattributes file to the default branch (e.g. master or main) of the project before it will have any effect. Changes to .gitattributes files in any other branches will have no effect on how diffs are viewed in the GitLab UI.
You must also commit the .gitattributes file with UTF-8 encodings for it to work, per the gitlab documentation
In Xcode, what's the best way to avoid Git conflict in the project file? (I am in manual git, not using Xcode interface for git)
I've cloned mapbox-ios-sdk from Github, hacked it, and now the remote master has changed. When I tried to pull the remote changes into my local, after merging there would be merge conflict in the project file. (Specifically, I mean the project.pbxproj in the .xcodeproj)
I do not really think project file should be put into the ignore, since if there are any new files the project file, the .pbxproj file seems to be changed. (Or am I just plain wrong and this file should be put to ignore? But obviously it wasn't on ignored in the mapbox-ios-sdk to begin with. People need the project file after all.) But I've also ran into this conflict before in my collaboration project with another collaborator and it's keeping me from using Git altogether.
Should I figure out how to manually resolve conflict or is there a better way to deal with this?
A lot of websites simply suggest to use a .gitattributes file with:
*.pbxproj merge=union
We're gonna try this approach before trying to use scripts. If we find any issues I'll be sure to update this post. Also if anyone else has comments to this approach please include.
.pbxproj will change when you add new files to the project. There will be conflicts if two or more collaborators add files at the same time (without getting one another's changes first). We are avoiding this in my project by following these steps before and after adding new files:
Before adding a file, commit your changes, then pull from the master so that you have the latest.If someone has added a file, you now have the latest .pbxproj
Add your file(s).
Immediately commit and push your changes up to the master (hopefully, before another collaborator has added another file).
It's wimpy, but we don't relish manually resolving .pbxproj conflicts.
Also, see this Stack Overflow question with excellent responses: How to use Git properly with XCode?
You should check my script xUnique, it is now the best solution to merge Xcode project file before Apple takes action on it.
What it does & How it works
convert project.pbxproj to JSON format
Iterate all objects in JSON and give every UUID an absolute path, and create a new UUID using MD5 hex digest of the path
All elements in this json object is actually connected as a tree
We give a path attribute to every node of the tree using its unique attribute; this path is the absolute path to the root node,
Apply MD5 hex digest to the path for the node
Replace all old UUIDs with the MD5 hex digest and also remove unused UUIDs that are not in the current node tree and UUIDs in wrong format
Sort the project file inlcuding children, files, PBXFileReference and PBXBuildFile list and remove all duplicated entries in these lists
see sort_pbxproj method in xUnique.py if you want to know the implementation;
It's ported from my modified sort-Xcode-project-file, with some differences in ordering PBXFileReference and PBXBuildFile
With different options, you can use xUnique with more flexibility
Check README file for more details.
In most case, you can fix the merge by following code, remove the lines which git adds:
#!/bin/bash
FILE={PRODUCT_NAME}.xcodeproj/project.pbxproj
sed '/======/d' $FILE | sed '/<<<<</d' | sed '/>>>>>/d' > temp
cat temp > $FILE
rm temp
but if you rename the group of your project and it leads to conflicts, you will manually delete the extra lines of your original group.
When this is caused by adding files from two or more collaborators/branches (which in my experience has always been the case to date and can be checked by looking at the diff) I do this:
Resolve the conflict by "use ours" or "use theirs" (whichever has added the most files).
Commit (this produces a repo that contains all the added files but some are not in the project).
Within Xcode use "Add Files To..." to add the missing files from the other collaborator/branch (they are easy to find as they are in the project directory and Xcode usefully highlights them for you).
Commit.
(I am not convinced step 2 is really necessary - but feels neater to me).
You can also use Mergepbx manually do it as follows
Install Mergepbx using brew.
brew install mergepbx
Run a command each time you have conflicts in your project file to automatically resolve them.
git mergetool --tool=mergepbx PROJECT.pbxproj
I need to get master code in my branch So, I was taking pull from master and I have a change in my .pbxproj file and master has different configuration. So, It was showing conflict in .pbxproj file. Follow these steps to resolve it
Open .pbxproj in Finder->
Right click on file Choose Show Package Contents->
Choose .pbxproj file and open it with TextEdit->
It will show conflict lines as below.
<<<<<<< HEAD"
// head changes
===========
// Your changes
>>>>>>>>
You have choose the right one from head Changes and your changes and Delete the rest.
Now commit you code
git add .
git commit -m"conflict resolved"
git status // Check you files status
If everything is fine the push you code.
git push
I made an app for fixing things in Xcode project files when these sort of things go wrong. You'd still have to do some manually merging first though, unfortunately.
https://itunes.apple.com/us/app/xsaviour/id1449886415?mt=12
If all else fails, while tedious. you can open your pbxproj in your git client, then manually, go file by file and ensure each one is either removed or has 4 lines (6 occurrences).
I had the same problem, so I wrote a tool in Swift that will resolve conflicts due to adding, deleting, moving, and renaming files and groups. You can set it up as a git merge driver so the script runs automatically when you merge a branch.
You can check it out here: XcodeMergeDriver
I use svnX.
When importing project, I check "no ignore" option. (for importing libOAuth.a, ...)
But one file is causing a small problem.
UserInterfaceState.xcuserstate
What is this file?
Can I ignore this file? Is it important? Should I commit this file?
What is this file?
You can open it in property list editor and have a look -- It stores things like your workspace/project document layouts, nothing you would lose sleep over if lost.
Can I ignore this file?
You would ignore it in all but exceptional cases. It's easily reconstructed, and should be considered local to your system's user account. To stretch imagination or reason to track it: If you worked by yourself and mirrored your user accounts, then you might want this information synchronized among your machines. Sure, you could track it, but it would produce a lot of unnecessary revision control noise.
I recommend ignoring files that match these patterns:
*.xcuserstate
project.xcworkspace/
xcuserdata/
Basically, the only thing under MyProject.xcodeproj that you want checked in is project.pbxproj.
As of Xcode 7.3.1, UserInterfaceState.xcuserstate's are binary-formatted plist files that can exist in either of project files or workspace files. They are user-specific and many can be present in a given Xcode project or workspace.
Among other things they contain the current target your project is set to, the currently open file, and cursor position. These files can be saved to disk frequently if Xcode has the associated project open.
To convert the contents of the binary plist files to a more human-readable XML format you can use this plutil command in the terminal:
plutil -convert xml1 UserInterfaceState.xcuserstate
These files can safely be ignored in most cases.
I've got an Xcode project under git and I've got a "experimental" branch off of my "master" branch. Both branches have diverged since the branch (so no fast-forwarding!), and I am merging "experimental" into my "master" branch.
I've setup a .gitattributes file to treat a particular Xcode file (project.pbxproj) as binary, as it should be treated as such. However, I'm not sure exactly how to merge it. I'm not sure what that particular file does, but if for example it handled which files were added to the project there's no way I can merge them, and therefore I'd have to manually add certain files back to the project (possibly not remembering them all). How do others handle this situation?
Also, I've read that you have to manually update binary files (obviously) or copy over different versions. However, once I'm into the merge process the file in my working copy is the "master" version. How can I access the "experimental" version? I can't check it out as it would disrupt the merging process.
Thanks for your time!
In general, for binary files, I recommend a copy-merge type of .gitattribute directive.
That is, I just copy the file coming from the remote end of a merge.
For .pbxproj files however, that may not be a good option, as described here.
Wrapping these files would only make the problem worse as far as I can tell - as you wold be completely unable to merge changes.
While you can merge project files in some cases, it's not something that you should
count on being able to do. The basic recommendation is to avoid editing the project files at the same time as someone else.
I like versionning projects files (like the ones for Eclipse), only if I know they are:
not modified that often (certainly not by each developers)
only using relative paths
no data specifics to one workstation
In short, if those files are not to be merged (or will only be trivial to merge), I want them in a VCS. In your case, that may not be so useful to have them in said VCS in the first place.
Note: as mentioned in the Git manual:
During the merge, the index holds three versions of each file. Each of these three "file stages" represents a different version of the file:
$ git show :1:file.txt # the file in a common ancestor of both branches
$ git show :2:file.txt # the version from HEAD.
$ git show :3:file.txt # the version from MERGE_HEAD
Our VB6 guy was part of the last RIF (Reduction in Force). The work he did has been split between me and another developer. We often are both are making changes to projects at the same time. This isn't a problem with CVS since we are working in different areas. However VB6 seems to modify the Reference section and change the paths each time either of us touches a project. Since we don't have the exact same path setup for out source trees we run into merge conflicts on the vbp file all the time.
Is there any way around this other than the obvious method of changing our setup so we have the same directory structures?
I would suggest two things:
Don't commit the .vbp unless you add a file to the project.
Mark the .vbp as read-only and check it in as such into your repo. When users check it out, it should still be read-only which will prevent changes to reference paths (and seemingly random reordering of the file) from being saved. When you have to make a change to the project--make the file read-write, save the change and then make it read-only again before committing.
Depending on your version control system, it is possible to automate this problem away. Both Subversion and Mercurial support hooks - scripts that are triggered by certain events, like check out, update, or commit. We wrote a fairly simple script that was triggered on commit: it looked to see if there was a .vbp in the commit package, and if there was, ran a "normalisation" routine that
put all the .cls/.bas/.frm files at the top of the .vbp, in alphabetic order
put the references section in alphabetic order
lower-cased the reference paths
The rest of the file is left alone, since it's only the first three sections that VB seems to delight in messing about.
Consequently, most of the time when you commit, and haven't made any substantive changes to the .vbp, the hook script restores your .vbp file to a canonical, ordered, state (like a revert), which has the effect of removing it from the commit since it's no longer changed.
In the event that you do add a new file or reference to your project, the consistent alphabetical sorting of the VBP lines means that merge conflicts are avoided since your VC merge algorithm can easily and correctly detect the changes.
We wrote our script in Javascript and execute it using Windows Script Host since, for Windows boxes at least, this removes the dependency on an interpreter like Perl/Python.
Hooking up this script to new VB projects is a 30 second job. The advantage over other manual approaches is that you don't have make any conscious effort to deal with the VBP file. Just commit it with everything else and the script takes care of the rest.