Don’t think we’re ever going to git on board with the rest of the world’s VCS of choice these days, just curmudgeonly mutter forever about the near-infinitely superior Veracity languishing in near-total obscurity; but if you’re going to git on with other people these days you don’t have much choice it seems, and hey we can actually git down with SourceTree these days not too badly (2.0 is just out, and looking sharp) … except when it totally trashes an Xcode project merge. Oh, right, that’s like EVERY @(#$&@%^!!! SYNC it seems. And then all in earshot git treated to a choice Troll Rant™ about burning it to the ground and then nuking it from orbit and then it’ll be time to really git serious. If you have more than one person trying to git any real work done, we’re sure you know the feeling.
But from one Michael Krause comes word of a handy-looking little tool for possibly reducing your blood pressure in these situations:
xcodeprojer is a Python script that brings your project.pbxproj files in order. It can transform any kind of JSON, XML or plist format into an internal representation and generate exactly the same commented plist format that Xcode itself uses.
Without relying on Xcode at all this can be used for tasks like this:
- Ensure the canonical plist format of the project before checking in a new version.
- Perform custom modifications via these steps
- transform your project into JSON or XML.
- manipulate the JSON or XML object tree in a language of your choice.
- emit JSON or XML and let xcodeprojer create the proper plist for you.
- Perform custom modifications directly via Python with xcodeprojer as a module.
- Repair broken projects, a failed parse reports the line and column where the parser failed.
- Doing all of the above even on a non-Mac computer because it is written in pure Python…
That should reduce our falling back to the git pretty workflow every time two people work at the same time. We hope.
A considerably lesser but still regularly occurring problem we git annoyed by is figuring out how to git a build number that makes some kind of sense automatically. And we can git you some help with that too: here is the risibly named post
This script uses the PlistBuddy command line tool to edit the build number of the Info.plist in the /foo/DerivedData/bar directory, the target’s build directory. This is why git isn’t dirtied when the build number changes. It doesn’t matter what you’ve entered in your Info.plist screen in Xcode. It also updates the build number for every build, not just the first build after a total clean … It uses the git commit count for the build number, but if it detects that we’re using our Debug build configuration in Xcode, it suffixes the build number with the current git branch name. This avoids potential build number collisions across feature branches under simultaneous development
That sounds … well, tolerable, actually, can’t think of a number-related problem we’ve had that wouldn’t have avoided.
And as a final note, it seems that even command line git these days can be somewhat more advanced of interface than banging two rocks together in the dark and hoping sparks fly out:
UPDATES:Continue Reading →