Postpostmodern » Git http://postpostmodern.com Speaking of web development. Wed, 11 Jan 2012 00:21:50 +0000 http://wordpress.org/?v=2.9.1 en hourly 1 Git Yr Remote Set Up http://postpostmodern.com/2009/02/05/git-yr-remote-set-up/ http://postpostmodern.com/2009/02/05/git-yr-remote-set-up/#comments Fri, 06 Feb 2009 01:46:02 +0000 Jason Johnson http://postpostmodern.com/?p=323 Last week…
Jason
I started using Unfuddle for [redacted]
I like it so far.
Trey
it’s a good service
I’m going to move all my private repos there
Jason
if you just want online repo storage, why not just use your Slice?
Trey
I should do that
Jason
It’s super easy
Trey
yeah?
you should blog it
Jason
ok.

So here is how to get your remote git up and go

Setting up a remote Git repo and connecting via ssh in a nutshell:

First, we install git on the server. I’m using aptitude on Ubuntu for this. Next, we have two options: we can just set up a bare git repo and push to it using an existing user; or, if we want to be able to safely share the repo with others, we can set up a git user. After setting up the git user, we create the bare git repo, chown it to the git user, and push to it from our local machine.

On your slice…

  1. Install Git

    sudo aptitude git-core

  2. Add the Git User (If you want to use an existing user, skip to step #7.)

    sudo adduser git

  3. Set up ssh key (standard procedure)

    su - git mkdir .ssh chmod 700 .ssh nano -w ~/.ssh/authorized_keys

    (Yes, I use nano. What of it?)

    [ paste in public key and save the file ]

  4. Exit su

    exit

  5. Give the Git User a special shell that only allows git commands

    sudo nano /etc/passwd

    [ Change git’s shell from /bin/sh to /usr/bin/git-shell ]

    [ Save /etc/passwd ]

  6. If you have set up your sshd_config to only allow specific users, you’ll need to add git

    sudo nano /etc/ssh/sshd_config

    [ Add git to AllowUsers (near the end of the file), e.g.: AllowUsers jason git ]

  7. Reload sshd

    sudo /etc/init.d/ssh reload

  8. Create a dir for your repos

    sudo mkdir /var/git

    sudo chown `whoami` /var/git

  9. Create your first bare repo (--bare means no working dir; i.e. just the contents of .git)

    cd /var/git mkdir test.git cd test.git git --bare init sudo chown -R git .

Back on your local machine…

  1. Go to there

    cd /path/to/test

  2. Add your remote (just as if it were somewhere like Github)

    git remote add origin ssh://git@slice1.example.com/var/git/test.git

  3. Push all your branches

    git push --all

N.B.

  • If you use something other than Ubuntu and aptitude, your git-shell may be located somewhere else. Try which git-shell to find it.
  • If you’ve changed your ssh port to something other than 22, you’ll need to do something like this: git remote add origin ssh://git@slice1.example.com:8822/var/git/test.git
  • To allow others to contribute, put their public key in /home/git/.ssh/authorized_keys, but remember, you can’t log in as git; so, you’ll need to edit it as root with sudo.

Questions? Comments? Recommendations? Let me know.

]]>
http://postpostmodern.com/2009/02/05/git-yr-remote-set-up/feed/ 3
Gitup! http://postpostmodern.com/2009/02/01/gitup/ http://postpostmodern.com/2009/02/01/gitup/#comments Sun, 01 Feb 2009 18:49:34 +0000 Jason Johnson http://postpostmodern.com/?p=296 Gitup + Transmit = Really Simple Publishing

Deploy vs Publish

There are many ways to deploy a new version of a web site. If it’s a web app, you normally want to use a complete deployment solution like Capistrano or Moonshine. But if you need to update a static HTML site or a simple PHP site, you usually just need to upload the changed files. This is often referred to as publishing as opposed to deployment. There are obviously several ways of doing this. Many file transfer apps have synchronization features. Publishing features can also be found in many editors/IDEs.

The Pain of Publishing

I’m a simple man. All those fancy publish/sync features always seem to be a hassle or else they’re built-in to a less-than-ideal coding environment (I’m looking at you, Coda and Espresso). Editing in Textmate and dock-sending to Transmit is about as fancy as I get. No sync. Just uploading files. The problem is, it’s hard sometimes to keep track of all the updated files that need to be uploaded once a new page is added, feature is complete, etc. Git knows what’s changed (if you’re not using Git or some other SCM, you should be), but going through the logs is a pain.

Gitup and Go

So, yesterday, I wrote a Ruby script to do simple publishing. It’s called Gitup. You tell Gitup which Git commits you want to publish, and it finds all of the changed files and sends them to Transmit. If you have Transmit’s dock send feature set up, Transmit will upload the files to the appropriate server and directory. Gitup will even let you preview the list of files that it plans on uploading.

It’s super-simple and quick. Much quicker than any ‘publish’ feature I’ve seen.

Examples

Send files modified in the last commit to Transmit (Gitup will let you know how many files will be sent and offer you the option to view a list of the files or abort.):

gitup

Send files modified in the last 3 commits to Transmit:

gitup -3

Send files modified in the last 3 commits to Transmit immediately (no prompting or anything):

gitup -s -3

Send files modified since yesterday to Transmit:

gitup --since=yesterday

Send files modified since Monday to Transmit (quotes are required):

gitup --since="last monday"

Send files since the specified commit to Transmit:

gitup dcd2c68..

Open files added/updated between the two specified commits in Textmate:

gitup --application=Textmate dcd2c68..bf75dd6

Disclaimer

Please note that Gitup is brand new. It could be buggy. I’m just sayin’.

]]>
http://postpostmodern.com/2009/02/01/gitup/feed/ 0