Tag: version control

Gource: Visualize your Git logs in style

Gource: Visualize your Git logs in style

While generally there isn’t any real benefit in using this tool, it has been known to be able to increase your swag factor by up to 83% and it is, in the context of version control, the ultimate eye candy, an absolute must-have for catholic priests and Pedobear fanboys.

Gource was developed by Andrew Caudwell as a software version control visualization tool with built-in log generation support for Git, Mercurial, Bazaar and SVN. To find out more about it, you can check out the official page on code.google.com.

Software projects are displayed by Gource as an animated tree with the root directory of the project at its centre. Directories appear as branches with files as leaves. Developers can be seen working on the tree at the times they contributed to the project.

Gource Screenshot

Windows users can download it from the Downloads section of the project page, install it and run it normally from a command prompt, while in Linux, you can just install it from the main repository:

sudo apt-get install gource

To use it, just navigate to the working directory of a git repository and run it:

cd /path/to/your/repo

or, run it directly by just providing the directory as an argument:

gource /path/to/your/repo

Here’s an absolutely remarkable video showing 21 years (1991 – 2012) of the Linux Kernel development process in somewhere around almost three hours:

Check out the help/man pages for a list of all the options and how to use them. For instance, I sometimes use this as a screensaver:

gource -1920x1080 --fullscreen --multi-sampling -a 0.1 --time-scale 3.0 --loop -i 3600

Oh, and here are some fun interactive keyboard commands:

(V)         Toggle camera mode
(C)         Displays Gource logo
(K)         Toggle file extension key.
(M)         Toggle mouse visibility
(N)         Jump forward in time to next log entry.
(S)         Randomize colours.
(+-)        Adjust simulation speed.
(<>)        Adjust time scale.
(TAB)       Cycle through visible users
(F12)       Screenshot
(Alt+Enter) Fullscreen toggle
(ESC)       Quit

The documentation is a lot, but well structured and worth reading + there’s even a guide for recording / encoding videos if you’re not into third party video capture software.

Getting started with Git (Part I)

Getting started with Git (Part I)

What is Git?

Git is yet another one of those type of things I now cannot perceive life without. To just dive right into it and give it sort of a more academic definition, Git is a distributed version control system created by Linus Torvalds – yes, the same awesome guy who made Linux, that should reassure anyone.

While most other version control systems (i.e. SVN, CSV, SCSS, RCS, etc.) use a central repository model that holds the master copy of the code, Git stores all the repositories locally for all the clients using them. But seriously, the idea of its entire architecture and the way it works is so much better explained in so many other places and I think that learning about those things first is very important, regardless of your background in any other version control systems.

Where do I learn more?

For instance, I came here from SVN and CSV and mostly learned about it all from git’s official website Documentation page(s) and of course, Kevin Skoglund’s Git Essential Training video course on Lynda.com, both which I warmly recommend, as these posts are nothing but stripped down versions of some notes I took and are only here to help me out in a hypothetical situation in which I’m stranded on a deserted island, I build a computer out of sticks and stones and can’t remember how to clone my remote repositories so I can work myself to death.


So much for minimal writing… (I know (I know)). Git is a big deal, ok? It needed a bit of introduction – but no more, this first part will help you install and configure Git on a local machine so you can start working with remote git repositories. Some people might be happy enough with using local repositories, but personally I administer and / or have access to enough servers to go all remote, as it is easier, safer, more useful and frankly – the way to go. This guide assumes that:

  • You have SSH access to a Git server (well, this is quite improper – something remote to hold your repositories then)
  • Your dog is jealous of your terminal, as that’s your best friend (bonus points if you don’t have a dog at all (extra bonus points if you got rid of it because of the terminal))
  • You DO know a thing or two about version control
  • You DID RTFM
  • You ARE gay for Kevin Skoglund (no homo)
  • You’re running Linux or Windows (MAC OS is UNIX-based, so Linux stuff might / should apply)


  • Linux:
    sudo apt-get install git-core
  • Windows: go to git-scm.com and follow the download / setup instructions
    Note: Windows users should totally get and configure a ssh agent to manage their keys. Punching in the password on every pull / push can induce paranoia and intense thoughts of violence against the machines and self mutilation.


We have three separate levels of configuration (System level, User level and Project level) but we want to go for the User level one – more information on these can be found in the manual. So, open up a terminal / console and let’s start configuring:

git config --global user.name "Mike Johnson"
git config --global user.email "mike.johnson@howto8165.net"
git config --global core.editor "nano"
git config --global color.ui auto

To fix the ever-existing problem with new line handling (LF normalization), we need to also add these:

  • Linux:
    git config --global core.autocrlf input
  • Windows:
    git config --global core.autocrlf true

Git auto-completion

Windows should have it already. That thing, in pretty much any UNIX environment when you press Tab in a terminal to auto-complete your sh*t or suggest more of it? Yeah, for some reason, you don’t get that by default (in Linux at least). So it kind of needs to be installed:

cd ~
curl -OL https://github.com/git/git/raw/master/contrib/completion/git-completion.bash
mv ~/git-completion.bash ~/.git-completion.bash
nano ~/.bash_profile

and put these in there:

if [ -f ~/.git-completion.bash ]; then
    source ~/.git-completion.bash

Terminal colors

When working with branches or remotes, it is useful to have the terminal display the name of the currently checked out branch in the prompt. So, basically just edit or create a .bash_profile file in your user’s home folder and add this line:

export PS1='$(__git_ps1 "\e[1;32m[%s]\e[0m") \w $ '

This will have the effect of displaying the current working directory followed by a space, a dollar sign and another space on any directory that doesn’t contain a git repository. On directories that do contain repositories, it adds the bold green name of the branch before all of the above, in square brackets.

For the sake of making it all just a bit more customizable, in terms of colors at least, you can add this list of variables to your file and use them implicitly.

txtblk='\e[0;30m' # Black - Regular
txtred='\e[0;31m' # Red
txtgrn='\e[0;32m' # Green
txtylw='\e[0;33m' # Yellow
txtblu='\e[0;34m' # Blue
txtpur='\e[0;35m' # Purple
txtcyn='\e[0;36m' # Cyan
txtwht='\e[0;37m' # White

bldblk='\e[1;30m' # Black - Bold
bldred='\e[1;31m' # Red
bldgrn='\e[1;32m' # Green
bldylw='\e[1;33m' # Yellow
bldblu='\e[1;34m' # Blue
bldpur='\e[1;35m' # Purple
bldcyn='\e[1;36m' # Cyan
bldwht='\e[1;37m' # White

unkblk='\e[4;30m' # Black - Underline
undred='\e[4;31m' # Red
undgrn='\e[4;32m' # Green
undylw='\e[4;33m' # Yellow
undblu='\e[4;34m' # Blue
undpur='\e[4;35m' # Purple
undcyn='\e[4;36m' # Cyan
undwht='\e[4;37m' # White

bakblk='\e[40m' # Black - Background
bakred='\e[41m' # Red
badgrn='\e[42m' # Green
bakylw='\e[43m' # Yellow
bakblu='\e[44m' # Blue
bakpur='\e[45m' # Purple
bakcyn='\e[46m' # Cyan
bakwht='\e[47m' # White

txtrst='\e[0m' # Text Reset

That should be it for now… Just as a reminder, in case you missed my fascinating post on SSH auto-login – check it. It can save lives when working with Git. As much as I would like to stall, however, the next part of this guide will be a long thorough list of pretty much all the git commands you’ll be probably using all the time. It saddens me greatly to have to go through the miles of notes I have taken and attempt to cover even more stuff in detail, being descriptive and coming up with all sorts of scenarios…

Oh, and after that, there’ll be part III (God only knows how many parts this series will have in the end) in which I’ll be describing a highly effective workflow technique that has helped me a lot. Yeah, that would conclude this series and I’ll finally be able to easily sleep at night knowing that my volatile thoughts are well stored and safe – I like this blog, it’s like my own personal pensive. Only thing left after that is to write a guide on how to properly install and configure Git on a server / a Git server 🙂

All right, great, we’re done with the basic stuff. Make sure you check out the next post in the series for even more basic stuff, or if you think you’re ready for more, with all due respect bl*w me, do you have any idea how long it takes to make a post like that? That’s irrelevant, as opposed to Getting started with Git (Part II).