How Can: Sharing Your Codes to the Git Hubs?

August 2nd, 2008 by rickbradley 4 comments »

These days it seems that everyone is on the github tip – cloning like a shitty star wars prequel, forking and pulling like a lobster banquet. With github’s success have come a few growing pains – GFS is evidently a rude ho, which means that sometimes you can’t always just take the bus and get there, metaphorically speaking.

Since git doesn’t rely on a centralized repository, github occasionally going pensive like a French actress shouldn’t really cramp one’s style as far as development is concerned. Just commit locally, gitjour with your friends, and when github is back up, git push github master. Badda bing.

It could conceivably be a bit of a headache if you’re hoping to deploy servers with capistrano or vlad and you’re relying on one single service to be up whenever you want to deploy. Since git is so decentralized, however, it seems only natural to just use that decentralization to our advantage and try to eliminate single points of failure. Redundancy, bitches!

So let’s talk about how OGC rolls.

sharing your codes to the githubs

We were hosting our own internal git repos on our own server before github was publicly available (well, to be fair it was Michael’s server, and we eventually broke the lock off the wallet and rented some slicehost action). Once github came along we hopped on and started pushing our open source projects over there as well. We were pushing to both repositories “by hand” for a while, meaning that we’d git push origin master and then git push github master.

First off: ass pain. We could make some aliases or shell scripts, or maybe use git push-all. Meh. Second off, this ain’t DRY – the opportunities for lost or mismatched codez on different servers are too-ubiquitous (“toobiquitous”, in fact) for my liking. Third off, this is clearly an open rabbit hole. Aren’t we obligated to climb into it?

So we made a number of changes. Among them, we started using gitosis to manage our repos (both public and private) on our slicehost. Then we made some configuration changes so that, once a project is setup, pushing to our slicehost repository for a project will automatically force a push to our github repository for the project. Sweet.

So, now, mirroring is easy, though setup on a per-project basis is still a bit cumbersome. We want to document what we’ve done, not because it’s beautiful (yet) but to get it out there and then improve it. Oh, and (to drop the Royal “we”) because ymendel keeps bitching that I need to write this damned blog article. [waves to Yossef.]

Here’s how we’re doing the mirroring… In the discussion that follows there are three machines involved: (1) a local workstation (or laptop, as the case actually is) where I’m doing development work, I’ll refer to it as “local”; (2) a git repository host under our control, which will be running gitosis, to which we push, and which then mirrors to github, called “internal”; and (3) Suggestions for process improvement are very welcome as there are still a few too many moving parts involved in setting up new projects.

Initial Setup

To get things set up initially, get yourself a unixy/linuxy host where you can set up gitosis for hosting. Slicehost, linode, some dude’s box, whatever.

Per-project Setup

UPDATE 2009-04-08: This is the start of the no-longer-necessary section. Check out the new hotness.

(One question I have is, is there a way to do this with gitosis that doesn’t involve logging in on the server to add the remote and setup the hook?)

UPDATE 2009-04-08: This is the end of the no-longer-necessary section. Check out the new hotness.

For troubleshooting, we adopted Evan’s idea and have a log file in the home directory of our internal server’s git user. The log file will show the output of attempting to git push --mirror to github.

Anyway, happy codes sharings!

4 Responses to “How Can: Sharing Your Codes to the Git Hubs?”

  1. Yossef Says:

    Jesus, finally! That image was worth the wait, though.

    Good article, man. Really, much of this comes down to steps 5 and 6 of the per-project setup (or · and · on your numbering scheme) being a pain. I think Evan didn’t much care because he set it up for only Rubinius, but we have to go through the pain every time we start a new flogic project.

    Also, for anyone reading this, make sure to label which key on the github account is used by the mirroring server. That way you won’t be tempted to delete it when it “doesn’t belong to anyone”. In fact, go ahead and ensure every key has a label, now that it’s possible to do so.

  2. Geoffrey Grosenbach Says:

    Why is it that anything becomes more humorous when pluralized?

  3. Damien Says:

    Thanks, your tutorial has been a great help.

    Here is a fork of gitosis to limit the need to login to the internal host:

    You just need to add to gitosis.conf: [repo foo] mirrors =

    The post-receive hook that check for mirror to update is created the first time push something to gitosis: hook

    If you repository is already in gitosis you have to add it yourself to ~/repositories/foo.git/hooks/

  4. Yossef Says:

    Damien, thank you so much. I’m looking forward to using your gitosis fork to create many, many new projects that will be automatically mirrored.

Leave a Reply