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
Related
I noticed that Xcode 7 creates a new .xcscmblueprint file in the xcshareddata folder. Will it be always auto generated? Should this file be added to the ignore list of the repository, or should it be checked in into repository?
Xcode 6 has the .xccheckout file, I've always gitignore'd that file.
I'm gitignoring them, for exactly the same reason as .xccheckout.
GitHub's maintained .gitignore added that too, for both Objective-C and Swift. https://github.com/github/gitignore
I think it depends. Just like #Ewan Mellor said the reason for ignore .xcscmblueprint is same with it for .xccheckout.
But whether ignore .xccheckout depends on your project . If you are using single project there is no need. If you are using workspace committing xccheckout file is need. For more the answer #Chris Hanson published is feed your need.
Back to the question. The content of the xcscmblueprint contains the main information about your project.
And I'm not sure it will change in the future. As the same reason for xccheckout I would like to commit this file.
The files seems to contain information pertaining to your source code repository. I think the "SCM" part of the filename stands for "Source Code Management". When looking at the one in my project, it indeed contains information about the GitHub repository that my XCode projects it (and also the git submodules that my repository uses, that's neat!). Of course, it also contains hashes so one could wonder if they are stable across developer, but I'd bet they are.
For that reason, I back up the advice given in many comments. You DO want to version this file.
I have some custom filter scripts that I use in my Git repo.
Currently, they are checked in along with my sources which sometimes leads to problems: when I check out a revision older than that where I added the filter scripts to my repo, I get warnings that the filters could not be executed because they cannot be found.
In order to overcome this, I want to put the scripts inside the .git folder so that they are present where I need them but don't make problems when checking out older revisions.
I want to keep them in the repo because the script contents are repo specific, so simply putting them to another location on my machine is not what I'm looking for.
Question is: are there some 'safe' locations inside the .git folder where I could store my scripts?
Safe in the sense that the scripts don't get cleaned up automagically or make problems with further Git versions.
The contents of the .git folder itself aren't very dynamic (what changes rather unpredictably are the refs and the logs, so just stay away from them).
If you take a look at the .git folder of any of your repos, you'll have a pretty good idea what is usually there.
AFAIK, folders in the top level of the .git folder do not usually start with a period, so you could just make a folder .git/.scripts to contain your private script files.
If you want, you can also make that inside the info folder -- that's really up to you and which you find more orderly.
Why not just include the names of the scripts in a .gitignore file? That way, your scripts are not tracked and you can place them anywhere you want in the repo.
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'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
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