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.

Bruce

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.

Bruce

Go BRUCE! :smiley:

OK, I did some more Google first, and came across this: http://shanesbrain.net/2008/7/9/using-xcode-with-git

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

[code]# xcode noise
build/*
*.pbxuser
*.mode1v3

old skool

.svn

osx noise

.DS_Store
profile[/code]

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.

Bruce

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: http://progit.org/book/ch7-2.html

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:
*.model2v3
*.perspectivev3
and to #osx noise
profile

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.

Bruce

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.

Bruce