gitweb – shorty

The Team demanded (or asked nicely) for a graphical overview of all the git repositories, so here is the quick way to do it:

  1. Install gitweb

       sudo apt-get install gitweb
    
  2. Make an empty directory that is the root of all the repositories e.g. pub. This is necessary since git has no concept of a root repository holding others

     mkdir pub/
    
  3. Change owner to the user who owns the repositories

     sudo chown -R git:git pub
    
  4. Now we link the repositories into pub/ (Move to pub/ and do)

     ln -s /path/repo1.git rep1
     ln -s /path/repo2.git rep2
    
  5. Now we open /etc/gitweb.conf and edit the variable to pub/

     $projectroot = "/path/pub"
    

Now http://server/gitweb should show the list of repos. If not you probably have to edit $projectroot in /usr/share/gitweb/gitweb.cgi too.

Advertisements

git hooks – reel in

In the last post I sketched out a simple jabber-notification script for remote git repositories. There are some things, that can be improved there.

First I added an additional argument to exclude the commiter from the message queue. I know that I commited, so I don’t have to be informed about that later (I updated my github repo). So, I have another argument in the call, but what now?
In pushbot.py there is a dict to hold the name of the commiter (or email) as key and the jabberid as a value.

But that in itself is pretty useless, so we have to tweak the hook a little to give the name of the commiter as 2 parameter. This is best achieved in using

git log -1

which gives us the last commit entry. Better stil we can add a formatting instructions like this

git log -1 --pretty=format:"%ce"

which gives us the email-address of the commiting party. I will use this as the key in the pushbot dict holding the jabber-ids to which the push-notification shoudl be sent. I don’t use the commiters name here, beccause of formatting hubub and the fact, that I am less likely to run into problems with doubles.

So, in pushbot.py I will add an email-address as a key

rcps_list={'email@server' :  'jabber@server'}

Now the commiter should not receive any message concerning his now commits. But still we could improve the notification message by using the very same git log statement.

In hooks/post-receive we could generate a more detailed message using

git log -1 --pretty=format:"%cn, %s"

Which gives us the name of the commiter and the subject line. Insert this into the message and you have a nice push notification with sufficient details to decide what you should do without too much overhead.

Git Hook, Line and Sinker

Selfhosting your git repositories is not a bad idea. In fact it is a great idea and it’s pretty simple too.

First you make a new directory on an accessible machine which by convention ends on .git. Something like /allmycode/repo1.git

Move into the directory and execute

 git init --bare --share

Great, we got ourselves a shareable git repository. If you dont’ want ro be the only one to be working on that repository and have no intention of making it public either you should create a user specific for git operations on the machine you serve your repositories from.
Let’s assume your specialized user is called “git”

You can now add ssh-public-keys from all parties that should have access on the repos via copy-ssh-id to /home/git/.ssh/id_rsa.pub and have a nice passwordless access-control.

Now we can start to work on the remote repository.
In you local working directory we

git init

and provide the user information that is used in the commit message

git config --global user.name "Your Name"

git config --gloabl user.email your@email.sth

This was all local, so let’s add the information about remote

git remote add origin git@server:/allmycode/repo1.git

this enables us to make a push to remote with the shorter

git push origin master

It is completely viable to add differently labeled remote repositories e.g.

 git remote add github sth@github

and push a specialised branch (without passwords for example) there via

 git push github public

Nice, self-hosted remote repositories! You can start collaborating. And when you do you, you might want to automate transferring the newest version to a testing server. You could do this with a cronjob and some copying, or, you could use git’s very own hooks, to be specific a post-push hook.
Connect to the remote repository and enter the directory hooks/. Here you find some nice samples, but we want something different. We want a post-receive hook, which means everytime somebody pushes changes to
the remote repository this action is called. So we create that hook:

touch post-receive

then we paste in

#!/bin/sh
GIT_WORK_TREE=/path/to/serverroot/ git checkout -f

and save. Make it executable and you made a git hook. Congrats!
Since we have a user named git who is the owner of all the repos on our remote machine we must add him to the group that controls the webserver paths (www-data or else) Full instructions to make the checkout work.

Now every push to the remote repository should trigger a checkout which hopefully makes the newest version available on the webserver.

But let’s tweak things a little. Say we want to be notified whenever a commit has been pushed. Email and telephone are viable but timeconsuming and you don’t want to, and frankly should not have to, bother. I think Jabber is a great way of getting the information across without spamming the whole team. So I made a little script to send a message to everybody who cares to give me his jabber-id. You can get it here via

git clone https://github.com/kodekitchen/punobo.git

If you add to the post-receive hook

 python /<path-to-repo>/pushbot.py "Something has been pushed."

not only will your testing/demo/development server automatically have been updated, but all listed members of the working group will be informed about it on Jabber.

Update on the .zshrc

I needed a little more information from my prompt so I extended it a bit

HISTFILE=~/.histfile
HISTSIZE=1000
SAVEHIST=1000
setopt autocd
setopt promptsubst

autoload -U colors && colors
autoload -Uz vcs_info && vcs_info

precmd() { vcs_info }
zstyle ‘:vcs_info:*’ enable git hg bzr
zstyle ‘:vcs_info:*’ check-for-changes true
zstyle ‘:vcs_info:*’ get-unapplied true
zstyle ‘:vcs_info:*’ unstagedstr “!”
zstyle ‘:vcs_info:*’ formats “%F{5}[%s:%r|%b]%u”
zstyle ‘:vcs_info:*’ actionformats “%F{5}[%s:%r|%b-%a]”

PROMPT=”%F{2}%n@%M:%F{6}%d%F{11}» “
RPROMPT=’${vcs_info_msg_0_}’

The result is a shell that lets me switch into a directory without typing cd and if the dir is version controlled it shows me the versioning system, the repo name, the branch I’m on and whether there are unstaged changes (indicated by !)

ZSH and versioning systems

Since oh-my-zsh didn’t work properly with ruby I had do remove it and all the nifty stuff went with it… So i was looking for a quick fix:

First I wanted to have the directory visible, i wrote this to the left:
PROMPT=”%n@%m:%F{6}%~ %F{11}%# “

Then I loaded vcs_info to get the information from git and put it to the right, that’s all I need:
autoload -Uz vcs_info
setopt PROMPT_SUBST
precmd() { vcs_info }
RPROMPT=’%F{4}${vcs_info_msg_0_} ${vcs_info_msg_1_}’
setopt AUTO_CD

It’s enough for me to work.