GIT and Xcode

:cry: GIT and Xcode aren’t working well together for me. When I want to sync with the tip, it’s making conflicts with juce, since by even opening the .proj file, I’ve made changes. Then I’m not GIT savvy enough to fix them with a sweep of the hand.

Anyone have a foolproof procedure? Remaking the whole folder every time seems silly, and completely contrary to the GIT ethos.


I second the call for help…cloning is getting a bit ridiculous. I tried to just trash the xcode file thinking(ala svn) that the pull would replace it… no such luck

OK, I’m actually going to have to read the GIT book I bought. I was hoping it wouldn’t have to come to this. I’ll report back.


Go BRUCE! :smiley:

OK, I did some more Google first, and came across this:

The gist is to tell GIT to treat the Xcode project file as a binary by ignoring the subfiles in .gitignore:

[code]# xcode noise

old skool


osx noise


And then setting an attribute in .gitattributes:

Jules, please could you change these in your GIT repo? Hopefully we will get those changes passed through, or else we may have to write this up as a sticky post.

I’ll read my book and see what it has to say too, but this sounds like a fix.


Most of those .gitignore entries are already there, and I don’t actually understand what the .gitattribute thing is supposed to do!

Here’s the ProGit book topic:

About what I said - first two attributes say treat the file as a binary, in GIT 1.6 there’s -binary flag that means the same, the third flag says leave it out of merges. The file is the actual xcode project info in the bundle, as opposed to a single users stuff.

I also wanted to add apps, so they don’t get mangled. I’m trying with .app and the same flags, but if it knows that it’s a bundle that probably won’t work. Best, as the sample does, to ignore the whole build folder?

I also added to #xcode noise:
and to #osx noise

I’m not certain though - maybe you need to commit those two files so we get them when we check out the repo? Maybe that’s why it’s not working well - you have some stuff locally but we don’t. Bear in mind, you also make all the xcode project changes, rarely pull them (I’d think). We have to pull yours, and that’s a lot of the shennanigans.


I’m still not entirely clear about what the problem is TBH… Surely all you’re looking for is a git command that says “pull down all the latest stuff and overwrite my changes”?

As for the project file, I don’t want it to be treated as binary, because I like to be able to review the changes in it when I’m about to check it in, so can’t really do that.

Hmm. In specific terms, finding that one command would help with juce. However, I’m moved to GIT on another project, partially based on juce moving, and I need a workable scheme anyway.

Maybe I can add those flags on my side and then I’d be better able to deal with pulling, while you can do what you need. I probably don’t need, nor want your private settings - window sizes, file cursor positions etc. but do need the project - changed settings, added files etc. I have to say, after one experience with diff shotgunning my file with <<<<<<<< head etc. and trying to fix it, I’m willing to treat that file as a binary for a long, long time now.

My version of juce did not pull down your .gitignore, if you’d already made those changes, btw.