commands are executables of the form 'git-<command>' in specific directory:
$ git --exec-path
/usr/local/Cellar/git/1.9.0/libexec/git-core
$ ls $(git --exec-path) | head
git
git-add
git-add--interactive
git-am
git-annotate
git-apply
git-archimport
git-archive
git-bisect
git-bisect--helper
In git's earlier years, it was just a set of git-<command> commands in $PATH, until the master git command was created (to 'rule them all' if you will).
git will actually pick up anything in $PATH of the form 'git-<command>' and allow you to run it as 'git <command>'. The downside of this, is that commands of the form:
git <command> --help
are intercepted by git and converted to:
man git-<command>
So your command cannot process the --help option itself when called like this (or it used to be this way a couple of years ago).
Edit: Another downside, is that some 'smart' command-line completion settings either have a hard-coded list of 'git <command>' commands, or look for said commands in the value returned by 'git --exec-path'. So you can't tab-complete git-<command> commands that you just drop into $PATH (at least not out of the box).
Some days are worse than others. Some days I rage out. Other days I realise that some people just don't know something and the best practice is just to educate them rather than raise your blood pressure.
It really depends on how much coffee and sleep I've had. Thanks for the kind words.
It's kind of nice that this just gives suggestions by default rather than running potentially breaking commands.
But as someone else here mentioned, you really want to understand the reflog in git. Everyone screws up at some point or another, and it's much easier to work through things when you can rely on the reflog to act as a safety net and an anchor of sanity.
I'm pretty sure your fetch logic is not right. First it assumes no arguments are passed. You assume origin/master (which is convention but not guaranteed) and also you assume a refspec isn't passed (in which case you need to rollback FETCH_HEAD).
