Lightweight Deployment With Git

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 b e 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 gode 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

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.

How the Internet Works 7 – Clients and Servers

Part of my goal with this series of posts it to demystify a lot of the jargon that you find when people talk about the internet. Each of these topics has a whole literature and special part of the internet dedicated to it, but just knowing what the general idea is a step in the right direction.

Today, I want to write about “clients” and “servers.” These are words that are used a lot in describing basic parts of the internet, so here is the answer:

The definitions go hand in hand, and so that is why I will introduce them together.

The client is someone that requests information server. The server is the one who responds to the requests.

If you think about it like a restaurant–when you go, you sit down at your table. You are the “client,” you can order whatever food you like. The waiter or waitress is your “server,” they respond to your requests.

In terms of the internet, you are the client. When you want to visit a webpage, say google.com, you make a request to get their webpage, and one of Google’s servers responds with the webpage.

When people talk about servers they can mean a million different things, but usually they are referring to some computer, (or part of a computer), that is responsible for “serving” up their website, or responding to the different clients who are requesting it.

“Client” and “server” go hand in hand with another pair of words: “front-end” and “back-end.” Front-end is the client-side, or the place where you, the end-user, is. Back-end is the server-side, where the website’s big computers and data-centers are. Now if I told you that “php is a server-side programming language”–you can start to decode that phrase.