Mercurial style aliases in git – and far more!

A cool thing that I really liked on mercurial and that I miss in git is the possibility of using shortcuts. Mercurial has them hard-wired. For instance, instead of typing hg status you could also type hg st or if you want to commit something: hg ci -m "Commit Message", which comes far handier than using hg commit and then waiting for the editor to start up and save the commit message file. There is also su for summary, and co for checkout. And this really saves you a lot of typing time, as these are the common tasks you want to use.

Git doesn’t come with that possibility, and while I wasn’t using it more often than Mercurial I didn’t bother to figure out how I could make git use some shortcuts. That’s of course possible, as Git is highly configurable. Now, I looked it up and I found out that there’s a highly sophisticated way of doing so.

Just open up your ~/.gitconfig. In it you will already find something like this. You’ve set this up for your first git usage – if you haven’t used git you’ll need to do it, otherwise git won’t work:

   name = Your Name
   email = youraddy@yourprovider.tld

What we’ll add is a new section, starting with [alias]

Now for each alias we want to set up, we write “alias = command”. So, this is basically exactly the way you would do your custom aliases in Mercurial if you ever did any. If you haven’t, for instance let’s get a shortcut for status:

  st = status
  name = Your Name
  email = youraddy@yourprovider.tld

We can even add flags, if we want. So if status is too chatty for you, try using the short flag:

  st = status -s

Now when calling git st you get something like:

A cli_ruby.bibtex
?? code/01_have_a_purpose/todo/

with A being a file added, D a file deleted, M for a modified file and ?? for untracked files. If you at any time prefer the chatty version for just this time, telling you how many commits your local HEAD is away from origin, and how to reverse changes, just use git status again.

Of course, the power comes, when using highly sophisticated commands that you cannot possibly type every time you want to use them. For instance, here’s a shortcut that not only sets the graph, abbrev-commit flags, but also sets date to relative and formats the message in a short and neat way and presents them in custom colors:

  st = status -s
  lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset %Cblue<%an>%Creset' --abbrev-commit --date=relative

The above I found at Shawn Biddles git config. He’s really a great guy, you should visit his site and YouTube channel, as well as his dotfiles on GitHub – there’s a lot to learn. One great additional feature of aliases is that you can even execute shell scripts or use other aliases. One example:

You work with a team on a project and you only want to display your own commits in the log. One can achieve this by hardcoding the name into the alias:

  my = log --author='Your Name'

That’s handy, but if you want to share your config with friends, they will have to alter the config. And even you might have different users and want to keep it flexible. So instead you could use the git function to get certain lines of your config, and execute it inside your alias

  my = log --author="$(git config"

So that’s already neat, but let’s go further: Say you have different aliases that all need to use the current username, for instance you might want to get all the commits done by you today. Now you know a good programmer is a lazy programmer, so rather than retype “config” so many times, let’s use an alias for it:

  me = config

And now we can do:

  me = config
  my = log --author="`git me`"
  today = log --since=midnight --author="`git me`"
  yesterday = log --since=day.before.yesterday.midnight --until=midnight --author=`git me`

Pretty neat, huh?

Branching in Mercurial

Branching is a great feature and is used extensively when you work with modern DVCS (as in those, merging simply works). When I still used to use SVN in our small teams (3-5 people) we never branched as that would just mean too much work-overhead with the merging process. Instead we all worked together in an office, each one of us had his files he was responsible for, and if someone else needed to change something in them, we communicated! Manually merging conflicts was hell, and in SVN merging mostly boiled down to manually merging conflicts.

Then I met Mercurial and I deeply fell in love with it. It could have as well been Git, Mercurial was just lucky there to meet me first (though after having worked a lot with Git as well as Mercurial now, I’d say, Mercurial has a leaner approach, simpler and shorter commands and is therefore nicer to work with). I really had to use Git when I started working as Ruby/Rails developer in 2011 and with that work branching came naturally along. Git has a sophisticated branching feature allowing you to have your own local branches alongside global branches (called remote branches), or to just pull branches you are interested in, showing you wich branches are merged into other branches, saving you from deleting branches that haven’t been merged yet, rebasing instead of merging to get a cleaner log, etc.

And Mercurial? Well I know that branching does exist, and I also know that there’s even another funny way, with bookmarks. You always read about them, when looking into books and tutorials about Mercurial. I also remembered reading something strange on the official docs of Mercurial (I guess, but I cannot really find it now), which suggests to use clones instead of branches. On my first day with Git I considered this a good practice – then I was shown what branches are ­čśë

Continue reading

Nachtrag: Versionskontrolle – Tutorial zu Mercurial

Ich hab gerade noch einmal etwas nachschlagen wollen, und bin dabei auf diesen unglaublich tollen Link gesto├čen:

Unter hat der Software-Entwickler Joel Spolsky (der einigen vielleicht wegen seinem Blog Joel on Software oder seiner Frage-Plattform “Stack Overflow”bekannt sein k├Ânnte) ein ausf├╝hrliches Tutorial geschrieben, dass noch mal eine Nummer ausf├╝hrlicher, mit vielen Beispielen und auch grafisch sehr anschaulich erkl├Ąrt, wie dezentrale Versionskontrollsysteme Funktionieren, und wie man mit Mercurial arbeitet.

Sehr lesenswert, aber leider auf Englisch.


Nachdem nun mein Studium wieder angefangen hat, und ich wieder (statt wie auf der Arbeit gewohnt, gemeinsam quick-and-dirty auf einem Netzlaufwerk zu Programmieren) nun wieder auf unterschiedlichen Rechner gemeinsam entwickeln muss, wird es wieder Zeit ├╝ber eine Versionskontrolle nachzudenken. Bisher hatte ich zwar immer SVN genutzt, aber in den letzten Jahren hat sich so viel im Bereich Versionskontrolle getan, das es f├╝r mich notwendig wurde, mich mal ├╝ber die aktuellen Entwicklungen zu informieren. Die Ergebnisse dieser Recherche m├Âchte ich hier kurz zusammentragen.

Bevor jetzt aber alle nicht-Programmierer schreiend wegrennen wollen: Haltet ein! ­čśë Versionskontrolle hat nichts mit Programmierung zu tun. Jeder, der irgendwie Texte auf seinem Rechner schreibt, Bilder erstellt, o.├ä. – also eigentlich alle, die Dateien erstellen, und regelm├Ą├čig bearbeiten, sollten einmal ├╝ber Versionskontrolle nachdenken.

Da ich selbst ein wenig Recherchieren musste (ich habe bisher nur mit CSV (nur sehr kurz und gezwungener ma├čen) und SVN gearbeitet, welche beide aus heutiger Sicht leicht veraltet sind), m├Âchte ich in diesem Eintrag kurz zusammen fassen, was Versionskontrolle ist, wie es funktioniert, und was zur Zeit stand der Technik ist.

Continue reading