git git commit -m "A beautiful commit message"

You know you've been there. Multiple times. You start writing a git command, switch to a different terminal or window to look something up (e.g. the exact syntax for some exoteric option combination), switch back to your command line and start typing your command from the beginning, including the initial git. And this gives you the rather depressing error:

git: 'git' is not a git command. See 'git --help'

This thing has always be so common that at some point in the past someone actually proposed to fix this internally in git, ignoring extra gits in the command line. The proposal was ultimately discarded (I don't remember the reasons, and I'm too lazy to browse the git mailing list to find the references, but I'm sure the actual reason was that it would have been too user friendly), so we're left with having to solve it ourselves, especially if we're particularly prone to it.

One of the nifty features of git is that if you have an executable git-whatever in your search path, git will happily allow you to use whatever as a git command, invoking the binary.

However, if you try to exploit this by making a git-git that is just git, for example with a symlink

ln -s $(command -v git) ~/bin/git-git

then it won't work, because:

fatal: cannot handle git as a builtin

You can work around this check by making a simple git-git shell script that does the work for you:

#!/bin/sh
exec git "$@"

and the live happily ever after:

$ git git git help | head -n1
usage: git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]

(of course, once you do it, it's recursive, just like the alias trick others have found before me).

(This post courtesy of my exchange with @glasnt@cloudisland.nz.)