Monthly Archives: January 2012

Lightweight Deployment With Git

Posted on by
3

I’ve used this setup so many times now that I wanted to write up a list post explaining how I do it. This method is something I found on this site, but I just wanted to add my own commentary.

The idea is that you are developing a website locally using git, and you want to be able to easily push to your live site with git. We will set up a remote repository on your server, and push to it.

Let’s say you have your local repository already set up. Log on to your remote machine. Navigate to a directory where you want to keep your repository. This does not necessarily need to be the same location as your code, and you actually probably want it to be a different place.

### On the remote machine
corn03:/afs/ir/group/paperless2> mkdir repo.git && cd repo.git
corn03:/afs/ir/group/paperless2/repo.git> git init --bare
Initialized empty Git repository in /afs/ir.stanford.edu/group/paperless2/repo.git/

The way this is going to work, is that we are going to create a post-receive hook. A post-receive hook means you can run some script after this repo has received a push. What we are doing here is checking out the current code to some directory, which we define as the GIT_WORK_TREE. You can make the GIT_WORK_TREE wherever you want. Then we make the script executable.

corn03:/afs/ir/group/paperless2/repo.git> cat > hooks/post-receive
#!/bin/sh
GIT_WORK_TREE=/afs/ir/group/paperless2/cgi-bin git checkout -f
corn03:/afs/ir/group/paperless2/repo.git> chmod +x hooks/post-receive

Now, on your local machine, add the remote you want to push to. On this first one, make sure you include the branch you are including, like master.

## Locally
> git remote add web ssh://jkeeshin@corn23.stanford.edu/afs/ir/group/paperless2/repo.git
> git push web master

For any future updates

> git push web

It’s pretty basic, easy to use, and works for lightweight deployment for a site by yourself or with a few other people.

The only issue I had was one time, my internet connection went down in the middle of deployment and the git process crashed. Then the next time I tried to push, nothing happened. After a little bit of searching, the fix was that there was a file “index.lock” that was created, and once we removed that file, it worked again.

Terms and Conditions: A Hobson’s Choice

Posted on by
Reply

Hobson’s choice: the choice of taking either that which is offered or nothing; the absence of a real alternative.
Origin: 1640–50; after Thomas Hobson (1544–1631), of Cambridge, England, who rented horses and gave his customer only one choice, that of the horse nearest the stable door, from dictionary.com.

I just joined another site yesterday. Or it was an app, I don’t really remember. It doesn’t really matter what it was. But this site had terms and conditions that you had to accept before using it. If you are just a general internet user, there is really nothing you can do about terms and conditions. If you want to use this site or app, you have to accept them. And if you don’t agree with them (and my guess would be in most cases, you would always be able to find something you don’t agree with), you simply can’t use the site.

This is the classic case of a Hobson’s choice, where there appears to be a real choice between two alternatives, but one of the options isn’t really an option.

Consider a case where you are at work and the boss wants you do to something, and he says to you: “Either you can do this, or you are fired!” In this case, you have “a choice”– you can either do this task or not. But assuming you want to keep your job, you are left with no real alternative, and similarly very little bargaining power.

The end users on the internet face this on basically every site you join. There are way too many terms and conditions for it to be at all feasible and reasonable for you to read them. Almost all sites present terms and conditions in a way where they *expect* you not to read them, but you *have* to agree to them to use the site. The sad state of affairs is that users *have* to a agree to a term sheet that they *almost certainly* never read. Many sites have terms and conditions hidden at the footer of their site that you implicitly agree to just by being there.

If I had to guess I would say that way less than 1% of Apple users read their terms and conditions sheets. I would be very curious to know that number.

So that’s about it. If you want to use the internet at all, just accept the fact that you had to agree to all these really stupid contracts that you have never read.