tags:

views:

119

answers:

2

I would like two things:

  1. to be able to change branches in git, and then Run or Build in Xcode without recompiling the entire project.

  2. have git ignore intermediate build files during merge, so it won't ask me to resolve any conflicts.

Putting the intermediate builds folder outside the project, or using .gitignore to ignore that folder, accomplishes #2 but not #1; I have to rebuild the entire project when I change branches, even if I did not modify any files.

+1  A: 

Well, you've answered #2 correctly yourself, so really your question only related to #1. I don't really see why Xcode would need to recompile things either - git won't change timestamp on unchanged files when switching branches.

Have you actually implemented the #2 solution, so that the entire problem isn't caused by git stomping on your build directory, which should be .gitignore'd?

calmh
The files are in the default build/ folder, and .gitignore ignores build/. (I think most everybody does this.) When do a build without editing source files, git shows nothing changed. Good. I close the project in Xcode, change the branch in git, and re-open the project in Xcode. The build files were not in git, so they were not changed, which means they are the wrong build files for the current branch and Xcode must rebuild everything. Then I return to the first branch and Xcode has to rebuild everything again. I understand why Xcode has to recompile.
Ross Carter
But if the files haven't changed (neither in content nor timestamp), the build files are not "wrong". Unless of course the new branch uses different build settings, in which case the is no way to avoid a recompilation.I'm not strong on Xcode, but could it possibly be that closing and reopening the project causes the rebuild?
calmh
The build files are wrong because the source files are different. Changing to a different branch changes to a different set of source files, but it doesn't change their accompanying build files; you're still using the build files from the old branch, and they are different. The dilemma is: if git ignores the build files, then they don't get switched when you change branch and must be rebuilt; OTOH if git does not ignore the build files, then it tries to merge them, which you don't want either.
Ross Carter
I see, you actually want the build files in your repository, so that they are checked out together with their source files, but avoid merges and conflicts?Take a look at marking them as binary; something like "*.o -clrf -diff" in .gitattributes. That will prevent merges. To prevent conflicts you would have to commit your new build files before changing to another branch, but that might not be a problem.In general, I think you will have to decide to either always keep the latest build files committed, or accept that a recompilation will be needed when changing branches.
calmh
Ah, mark them as binary, yes. Thanks.
Ross Carter
A: 

Xcode is going to do all of its data based on the timestamps of the files in question. If you replace the file with a newer file, then Xcode should notice that the timestamp of the file is newer than the timestamp of the build product and recompile it.

However, if you change it with an even older version of the source file, then it can't know that the build file isn't correct. It will just see that the build output is still newer than the source file, and so not recompile it.

In short, you can't know which files have definitely changed, and which have definitely not. You're better off doing a full clean+rebuild to make sure; otherwise you're going to lose time debugging when it doesn't work.

AlBlue