Github down!

Don't let anything stand between your PR and your repo

A Friday drama? #

It is 3:30 PM and your team is scrambling because nobody can push to upstream. The Sun is shining outside, and everyone would like to finish the last PR of the sprint so they can go get a healthy dose of light! But nobody can because github is down.

Since Linus Torvalds created git to manage the Linux Kernel source code, it has taken over the world. It is the swiss army knife of modern software development: incredibly versatile, and packed with features: A few universaly useful, some others too specific to be widely adopted and too sharp to even look at. Possibly the most overlooked feature is that since its inception it is a distributed nature.

We are very much used to pull/push/clone from centralized repositories and we don’t give much thought to the fact that these are not needed! Nobody is saying here that they are not convenient… But no team should see themselves stuck a single second because github is having a glitch. git has the functionality to enable team colaboration even in extreme circumstances.

Let’s take a look at a few options.  Humble Reality Check
While I would love to say that your pipelines will keep on running, or that you can update your board… You already know these are precisely some of the drivers behind GitHub et al.

Distributed by brute force: The humble patch approach #

For the lo gest time patches were one of the most common ways of distributing code changes. While the principle has not disappeared, it has been buried below several layers of abstraction. The idea isn’t strange to anyone: you compare two versions of the code, compile the differences and determine what needs to be added or removed to make them the same.

The appeal to us is that the humble patch can be distributed through a file server, or a usb key, an email chain. No network? No problem!

Generating a patch file #

Creating a patch file is very straight-forward:

# Checkout the branch missing the changes
git checkout <targetBranch>
# Generates the patch against the branch with your changes
git fomat-patch <changesBranch> --stdout > <patchName>.patch

Now take your file and share it with your team, one by one, or all at once. There are endless options!

Applying the patch file #

You should put a little bit more attention into this step, just making sure that the changes are applied in the right place, but this step isn’t any more difficult than generating the file. Once you get the patch file, you can just follow along

git checkout <targetBranch>
git am <patchName>.patch

And that’s it!

WorksForMe but insecure by default: the git daemon #

If you have a network and you trust it, you can serve your repo with a single command

git daemon --reuseaddr --base-path=/path/to/repo /path/to/repo

Since this will take over your terminal, maybe you want to daemonize it, and make sure it the server won’t go down if you logout

nohup git daemon --reuseaddr --base-path=/path/to/repo /path/to/repo &

Accessing the server #

To clone the code served remotely

git clone git://ServerAddress

You don’t need to specify anything else, since the path of the repo was defined on the server side. Pushing code is disabled by default, I’ll leave it as an exercise for people committed to this solution, but otherwise all the options are well documented in git’s manual pages.

More #

Yes, you can use git over http, https, ftp, ssh, and I guess that directly over NFS/SMB? But I am happy enough if any of these options get you out of trouble, or irritate you so much that I earn some space in your mind, and a response… (So Cozy by the way!)

Read the manual for more. ABC my friends, ABC!