Adding existing Xcode project to remote git Repo

I decided to post this as I found it a little frustrating finding good documentation on this anywhere. It seems that it was in bits pieces, so I’m posting it here, so I don’t have to go through the trouble anymore. Hopefully, others will find it useful as well.

There are two things you’ll need to do:

  1. Create the remote git repo
  2. Create the local git repo

Once you’ve done these, you should be able to commit and push those commits to your remote repo through Xcode. You won’t need to create the local repo, if you already have one for your project.

If you’re migrating a project from Subversion, you should export the project from the Subversion repo before starting. That will checkout your project, without the hidden .svn administrative directories. As git adds it own administrative directories, I imagine Xcode might get confused if both were there.

I use ssh to connect to the command line on the server where my git repos reside. You may need to adjust these commands for your environment.

On the remote server, change to the directory where you keep your git repos and execute these commands:

  1. mkdir Project
  2. cd Project/
  3. git init –bare shared=users

The –shared parameter is required if you need others to use the repo. The group, ‘users’ should be whatever group has access to the git repo. On my system, the git directory is owned by “me” with the group, ‘users’ having ‘rwx’ privileges (rwx-rwx-rx).

On your local computer, close Xcode and open up the Terminal app and change to your project’s directory and type these commands:

  1. git init
  2. git add *
  3. git commit -m “First commit”

Now launch your project in Xcode and go to the Organizer and click the Repositories tab. You should see your project under its repo name in the left pane.
Screen Shot 2013-01-10 at 11.44.21 AM

Click on the ‘Remotes’ folder under the repo name and then click the ‘Add Remote’ button at the bottom of the right pane. In the dialog box, type in a name for ‘Remote Name’ and then fill out the ‘Location’.

Screen Shot 2013-01-10 at 12.17.11 PM

The ‘Remote Name’ is arbitrary but, ‘Location’ should take the form of:
username@server_name:/path/to/repo. Click ‘Create’. If your info was correct, the dialog should disappear and you should be ready to push your commits to the server. When you go to push your commit, you should see something like this:
Screen Shot 2013-01-10 at 2.16.35 PM

Just click the ‘Push’ button and your changes will go to the server.

When working with a remote git server, you have to both, commit and then push, in that order. Commit only commits to the local repo. Push pushes the commits to the server. You’ll find both these commands under File->Source Control. Make some minor edits in your source and then try that now. You should be good.

A couple of tips:
Xcode gives you a key binding for ‘Commit’ (cmd-option-c), but not for ‘Push’. I edited my key bindings under Preferences and added cmd-option-p for ‘Push’. You can search for the ‘Push’ command in the key bindings search window and add one, if you like.

You can also commit your changes in the Organizer window, but, Xcode does not push these changes, so you’ll still need to push.

That’s it. Now I don’t have to worry about forgetting this.

EDIT: If you want to push to the remote server from the command line, you’ll first need to tell git the location of the remote repo. Use this command (ssh):
git remote add origin ssh://username@server/path/to/repo

Now, you can push your changes with this:
git push origin master

Where ‘master’ is the branch where you want your commits. I’m still learning git, but I believe git uses ‘master’, in the same way that subversion and cvs use the term, ‘trunk’.

Tracking multiple NSURLConnections

A couple of years back, when I first started playing with the new Leopard (10.5) ABI’s, I was looking for a project that would allow me to play around with things like Assocaiated References (AR’s) and Blocks

I spend most of my free time maintaining both Weather Vane and Audio Switcher, which still run under 10.4 and so can’t make use of any of the new ABI. After looking at a few of the examples of the new stuff on the ‘net, I decided I would try to use them to track multiple NSURLConnections. If you need to create and dispatch multiple, simultaneous¬†NSURLConnections, you’ll find that the ¬†NSURLConnection ABI does not provided a means of distinguishing between the data returned from each connection. One obvious and simple solution to this problem is to subclass NSURLConnection and add some identifying field that distinguishes each connection. I did just this some years back and thought at the time, that it seemed silly to have to do that. So, I thought I’d redo that project specifically using AR’s to track each connection. If you read the docs, you know that you can use AR’s to associate arbitrary data to a given object. When the connection returns data, you inspect the data you associated with it to determine which connection it is and then do whatever you need.

This actually works pretty well, but I wanted to get some opinions from other Cocoa developers about this method of tracking connections. You can read the thread here. Many of the comments were enlightening and gave me a couple more ideas to try. Well, I’ve finally found the time to re-work the project, but this time, instead of trying to shoehorn some ABI into the project, I tried to accomplish this task in a smarter way.

So, this time I decided to wrap an NSURLConnection in an object that acts as the delegate for its connection. This proved to be much cleaner, as now the connection object essentially tracks itself. Of course, this assumes that each connection needs to handle the returned data in the same way. If different connections need to behave differently, you’ll need to try something else. The project creates multiple http request and tracks the time it takes for the headers to come back and then how long it takes for the body of the request to completely load. Not exactly sure if how I time the connections is correct, but it’s neither here nor there for this project. The important part is the connection tracking. Here’s a screen shot:

NSURLConnection timer

Each object is added to an NSArrayController and its fields are mapped to the NSTableView’s columns. Unlike the first project, though, there is no logic in code to determine which connection is which. As the values change in each connection, Cocoa Bindings handles their display, which keeps things nice and clean. You download the project here. There is a file “entries” included with the project. Its just a plist of http urls you can use to populate the table instead of manually typing in urls, if you prefer. I haven’t done a line by line comparison of the two projects, but there is at least 30% reduction in code. I’ve decided not to upload the original project. It ¬†could use a bit of clean up, but if anyone wants to look at it, I’ll go ahead and post it.

As always, if you have ideas or questions, feel free to post.