git branch in bash prompt

2014-03-18 13:20:31 PST

Tags: ,

Adding ‘$(__git_ps1)’ to my .bashrc PS1 bash prompt was the greatest idea/discovery I’ve had in a bit, as now I know exactly what branch any repo I enter is on:

dan@dan-work:~/src/work-project/ (master)$ 

Cortex and the Cult of Done

2011-05-20 12:26:02 PST

Tags: , , , ,

I just stumpled upon the Cult of Done Manifesto on Hacker News yesterday and I like it. It seems like some good advice, and I sure haven’t been too productive as of late with my new job going on, so in the first act I’m releasing what I do have done for Cortex. I set up a github repo for cortex and pushed the latest code. The master branch is a slightly improved version of Cortex from where it was last year for the BCNet presentation and the modular branch is a work in progress to chop it up and make it more modular for better future extensibility. I’ve been stalled on it but as the guide suggests that may be mental and either way I should get what I have out there. Now I can more happily comfortably move on (if it’s been stalling me, which i think a little it has) or even work on it more, now with less “pressure” of some looming release ahead of me :). So there it is, Cortex.

Also, things like Febrice Bellard’s Java Script CPU emulator that can run Linux are amazing, imressive and inspiring, and make me realize I really need to to more hacking.

So here’s to getting stuff out there! I want in on the Cult of Done.

links for 2011-03-14

2011-03-14 20:37:36 PST

Tags: , ,

Github and primes rerelease

2011-03-07 23:23:42 PST

Tags: , , ,

I’ve setup a github account at and started pushing some code to it. So far cl-pack and my old primes project.

Running primes again was fun. PHP is still quite fast for an interpreted language. Lisp is nicely inbetween VM languages like C# and Java and interpreted languages like PHP. Ruby1.9 is definatly faster than 1.8 but still slower than pretty much everything else (sadly). Nothing really seems to have dramatically noticeably changed. The old stats I generated still seem roughly right-ish. As right as this “benchmark” can be.

A quick benchmark on a Athlon 5200+ sorted by running speed:

Prime number benchmarks
Benchmark machine: Linux 2.6.32-29-generic-pae #58-Ubuntu SMP Fri Feb 11 2011 i686 GNU/Linux

C results:
Compile [gcc]:          0.09 seconds
Execute:                0.60 seconds

x86 Assembly results:
Compile [gcc]:          0.08 seconds
Execute:                0.65 seconds

C++ results:
Compile [g++]:          0.44 seconds
Execute:                0.78 seconds

Haskell results:
Compile [ghc]:          0.85 seconds
Execute:                0.93 seconds

C# (Mono) results:
Compile [mcs]:          0.52 seconds
Execute [mono]:         1.18 seconds

Java results:
Compile [javac]:        1.38 seconds
Execute [java]:         1.55 seconds

Common Lisp results:
Compile [sbcl]:         1.00 seconds
Execute [sbcl]:         3.09 seconds

Erlang results:
Compile [erlc]:         0.54 seconds
Execute [erl]:          5.82 seconds

PHP results:
Execute [php]:          12.0 seconds

PERL results:
Execute [perl]:         14.3 seconds

AWK results:
Execute [awk]:          15.3 seconds

Python results:
Execute [python]:       15.7 seconds

Ruby 1.9.1 results:
Execute [ruby1.9.1]:    32.6 seconds

Ruby 1.8 results:
Execute [ruby1.8]:      73.4 seconds

TCL results:
Execute [tclsh]:        180. seconds

links for 2010-03-19

2010-03-19 00:01:55 PST

Tags: ,

links for 2009-09-13

2009-09-13 00:02:21 PST

Tags: ,
  • "Here we have tried to compile the best online learning Git resource available. There are a number of articles and screencasts, written and arranged to try to make learning Git as quick and easy as possible."
    (tags: git, howto)

links for 2009-08-11

2009-08-11 00:01:38 PST

Tags: ,

More work on the Git tutorial

2009-07-25 11:24:17 PST

Tags: ,

Ok, hopefully this will be the last mention of this for a bit. I’ve gone back and completely rewritten and expanded greatly on my old Git tutorial. It’s still at the same place, Mindstab’s Git Guide, just with a new name. It still needs lots more work and expanding, which will eventually happen, but probably not right now. As it is it’s now good enough to let stand on its own while I get back to cl-pack. It has everything you need to set up a repository and get it on a server in one of many configurations. It just doesn’t have a lot on longer term development and multi team management of multiple repositories and branches. Haha, I also recast it as an Alice and Bob story.

Old and improved

2009-07-10 10:32:05 PST

Tags: ,

Just a note, I updated my 2008 how to set up a git repository entry. If you’re curious, here it is’s Guide to Setting up a Git Server

2008-04-27 23:30:38 PST

Tags: , , , ,

This is a ‘living document’ in that I’ll try to keep updating it from time to time so it keeps working with git as git “matures” and as I learn more about git.
Last Updated 2009 07

I’ve found documentation on the setup of git servers and public repositories kind of lacking, so here is my best attempt at documenting what works for me. Feel free to comment with bugs or enhancements please.


1. Setting Up A Local Repository

Alice is going to start developing a project and she wants to add source control to it. There are a couple of reasons to set up a local repository that Alice likes including branch control, so that she can revert her code to previous releases, fix, patch or merge a bug fix, roll a release, and then pop back to the current development branch.

1.1 From Scratch

To set up a git repository for her project, Alice does the following:

alice@home $ mkdir proj
alice@home $ cd proj
alice@home $ git init

The project directory is now an empty git repository. As she creates files, she can add them to the respository with

alice@home $ git add newfile.src

And when she’s done work or at least reached some break point, she can commit the new files, and all changes with

alice@home $ git commit -a

1.2 From An Existing Project

Also, occasionally Alice gets excited and starts coding before creating a repository. To create a repository from an already started project is as simple as

alice@home $ cd ~/proj
alice@home $ git init

and either

alice@home $ git add .

to add all the files, or

alice@home $ git add file1 file2 file3

to add just some of the files, both followed by

alice@home $ git commit -a

for the initial commit of the code to the new repository.

2. Setting Up A Remote Repository

Some times Alice needs her repositories to be remote and internet accessible. Sometimes she needs to work on them from several locations, and sometimes she wants her project’s code to always be accessible to the public.

There are two primary methods for making remote git repositories accessible online. The first method is over ssh, which developers can use to both read and write to the repository and the second is through a dedicated git server which the public can use for read only access.

2.1 Remote Repository For Developer Only (ssh)

If Alice’s project is personal and she just needs a central repository to access from a few locations like both work and home, she can set up a repository on any unix machine she has access to as follows.

Alice needs to create a bare repository clone of her working code and then transfer it to the server she will be using as the repository host

alice@home $ git clone --bare ~/proj proj.git
alice@home $ tar -czf proj.git.tar.gz proj.git
alice@home $ scp proj.git.tar.gz

Then, on the server

alice@server $ tar -xzf proj.git.tar.gz 
alice@server $ mv proj.git proj

Now Alice can create working copies of the repository from anywhere, like work, and work on the code as normal as follows

alice@work $ git clone ssh://
alice@work $ cd proj
alice@work $ commit -a

However all this does is create a local clone of the repository and commit the changes to the new local clone. To push changes to the local repository back to the central repository, Alice does

alice@work $ git push

(As a note, Alice will also need to perform this clone of the remote repository at home so that her repository is aware of the remote repository, or she can use ‘git remote add’ to make her current original repository aware of the remote one)

When Alice gets home she can check out the latest changes with a simple

alice@home $ git pull

which pulls all the latest changes from the remote repository. Then she can develop, commit and push her changes and then the next day at work she can pull all those changes.

2.2 Remote Repository For Public Access (git://)

Now, to allow public read only access of the repository over the git:// protocol the steps of setting up a remote repository are all the same, however there are additional steps that need to be taken.

At a minimum, Alice needs to setup the git daemon on the server and tell each git repository that she wants to be publically accessible that it is so.

Setting up the a basic git daemon is up to Alice and her server’s distribution, but once it is installed and running, it will try to export any directory on the server filesystem that is a) a git repository, and is b) flagged to be publically accessible.

To make her repositories accessible, Alice does the following

alice@server $ touch ~/proj/git-daemon-export-ok

Now when Bob hears about Alice’s project, he can check out a copy of the repository himself as follows

bob@home $ git clone git://

Bob actually ends up with the a full clone of the repository and can work with the code, and if he wants he can make changes and commit them to his local clone of the repository as normal. However, the one thing Bob cannot do is ‘push’ his changes back to the central repository.

He can, however, even stay up to date with the repository with git pull

bob@home $ git pull

and he’ll always get the latest changes.

2.3 Shared Multi-Developer Public Repository

(Note: This is for those more used to CVS and Subversion style source control. Defacto and “proper” git style is outlined in section 3. Managing Multiple Developers, Repositories and Branches.)

Alice happens to have root access to her server and wants to set up a multiple developer git repository.

First she creates a git user group and makes a root git directory.

root@server # groupadd git
root@server # mkdir /git

Then Alice configures the git daemon to only export repositories in /git in the git-daemon’s config file

GITDAEMON_OPTS="--syslog --verbose /git"

Now Alice creates a shared repository. She untars the git repository like normal, but sets its group to git and makes sure it’ll stick by setting the stick bit, and then she makes it “shared” which means all the files are writeable by the group git.

root@server # cd /git
root@server # tar -xzf proj.git.tar.gz
root@server # mv proj.git proj
root@server # chgrp -R git proj
root@server # chmod g+ws proj -R
root@server # cd proj
root@server # git config core.sharedRepository true

And of course if Alice wants it to be publically viewable

root@server # touch git-daemon-export-ok

Now Alice has a git repository that several developers on the server can all use. Anyone in the git group can commit to the repository.

Alice’s friend Charlie wants to develop for the project so Alice gives him an account on the server. Charlie can then start developing just like normal

charlie@home $ git clone ssh://
charlie@home $ cd proj
charlie@home $ git commit -a
charlie@home $ git push

Alice can get these changes at home, and any she’s made from work with a simple

alice@home $ git pull

And if the repository was made public and exportable then Bob can checkout the code and keep up to date too

bob@home $ git clone git://
bob@home $ cd proj
bob@home $ git pull

3. Managing Multiple Developers, Repositories and Branches

The proper way to use git with multiple developers is for each developer to have their own repository and branches and have a central manager who pulls from all the other branches and merges the code together before release. This is how Linux works (git was created by Linux’s creator Linus).

Note: I know this is the proper way but I haven’t really had any experience with it, so until I get time to play with it unfortunately this part of the document will be empty. Check out the official git manual for a good idea of how this should be managed, especially chapter 4 Sharing Development.


Valid XHTML 1.0!
Valid CSS!
This is a personal web page. Things said here do not represent the position of my employer. is proudly powered by WordPress
Entries (RSS) and Comments (RSS).
22 queries. 0.410 seconds.