I’ve been using GIT as a source version control system for some time on my Macbook from within Xcode. It was Xcode and a tutorial that got me really started with GIT.

Then this past spring I spent several days importing all the zip archives of an enterprise production system (source in Java) into GIT repositories on my PC. The book “Pro GIT” was invaluable.

Most of my GIT work has been utterly routine – add a feature or perform some maintenance, then commit the changes. Push the changes to the main repository. Simple. Works.

However, on my big Xcode project, GasRad, which I mentioned in another blog post today, I didn’t do things simply. Rather, many months ago I faced a fork in the road when implementing some testing in the new version of GasRad. There were two almost equally valid ways to send parameters to a testing routine, and so I tried both. From the MASTER, I created a branch “alt_param_testing”. So far, so good.

Then, due to previously written problems with Xcode versions and IOS versions, my program quit running on my iPhone. So I gave up for a time.

Fast forward a couple of months, and I added Doxygen comments to my GasRad program. Very nice. Highly recommended.

Fast forward to this past weekend, and I had to modify the program in two small spots to allow it to compile in the newest Xcode / IOS version. One was some dumb nonsense about unallocated assets (Launch Images) and the other was some new nonsense Apple forced on apps for the latest version (needing root windows). My rant on this stuff was posted earlier today, so enough said about that.

What does matter is now I have a project in GIT with MASTER many, many changes older than “alt_param_testing”. What’s  worse, the current active branch really isn’t “alt” anything now, it’s the version of param testing that worked. Really, it’s MASTER.

However, using Xcode and another Mac program I was using “SourceTree”, trying to follow standard GIT practices to merge “alt” and “master” into a new single master branch proved impossible. It got so bad that the project in GIT was a writeoff. All gone. Thankfully I had a time machine backup to recover all but the last few days work, which I remembered – so all was not lost. Not really.

But the whole point of GIT is that you aren’t supposed to be ABLE to mess up a project so badly in GIT that you can’t recover back to where you wanted.

However, no such luck with Xcode or SourceTree. They hide just enough of the workings that the merge simply stalled but without the A/B editor windows (or a clear process) to resolve any conflicts.

I re-read the Pro GIT book, but it’s not really much help in this case. It’s not GIT, it’s the tools that are lacking.

The other infuriating thing is every time I start Xcode, there’s yet another binary file sitting in the pile of uncommitted things. Even after a commit. Why a binary ANYTHING is in the uncommitted files is beyond me. Xcode sets up GIT and sets up .gitignore, so it should be aware of what must and what must not go into a GIT repository.

For the moment I’m stuck in GIT hell – with a project where I cannot merge the two branches at this time  without some essential,  missing piece of information. Yippee.

UPDATE (5pm): After seeing this one ‘new’ file that changed and wanted a new commit, I decided to investigate. Copied the file name to the clipboard, then pasted into google. First 5 hits were all from stackoverflow and all referred to this file and “why is it showing up and needing commits?”.

It turns out it’s another UPGRADE ARTIFACT created by Apple. If you create a new project and git repository in the latest Xcode, this file is already in the new .gitignore file. Of course Apple does not offer to “fix” this in existing projects. so the solution offered was to run “git clean -f -d” to remove the file and then commit the  change. It appears to have worked.

The file in question is a system file that stores the location of windows, what’s open, etc. for Xcode on a per-project basis. While it might be nice to have  different Xcode windows open, settings etc. in each project, it’s not really a “source” file to be saved in most people’s opinion. Certainly not since it’s a file that will be updated EVERY time you run Xcode and do anything at all.

Glad one mystery / annoyance has been cleared up. Now back to the merge…