I thought it might be worth having a look at two things git allows I've abused
to remove some warts and toil from my day-to-day flow.
One thing git does is alias support. Anything under the [alias] key in ones
$HOME/.gitconfig is treated as a valid subcommand. This is fine for quick
things, like r as rebase or a for add, but you can also alias one-line
scripts, for example, here's a snippet from my .gitconfig.
it = "!f() { git fp && git r origin/master; }; f"
This demonstrates defining an ad hoc shell function named f and calling it
immediately. What's notable about this is that it is also calling a git
alias. git fp in this case is an alias for git fetch --prune and r we've
already mentioned is rebase, so this, verbosely, is,
$ git fetch --prune && git rebase origin/master
Another thing git let's you do is invoke arbitrary scripts that are named in
the format git-name. If the script is on the path, you can call git name and
the script, git-name, will run. My old process for pushing to a branch I had
authored was a bit verbose,
# on first push
$ git push -u origin/master current-branch
# afterwards ...
$ git fetch --prune
# and, after hacking, changes both behind + ahead on branch (rewritten history)
$ git push --force-with-lease
# or, if simply, without any `--force*` flag
$ git push
I wrote a script that does all of this, automatically, called
git-p,
which lets me call git p. It's doesn't work for all corner cases, and could be
extended to, but this fits ninety-nine percent of my use case. This worked well
for awhile, but I needed to build on it. I eventually wrote an alias called git up,
up = "!f() { git it && git p; }; f"
The point of up is to ensure my changes are always rebased on master before I
push. This is pretty handy but I've recently added yet another alias called
raise (also aliased as pr),
raise = "!f() { git up 2>&1 | awk '/http/ { print $2 }' | xargs open; }; f"
This scrapes out the remote output with the PR creation link that GitHub
provides after a branch is first pushed to the remote repository and funnels it
into open. MacOS X has open as the default way to open mime-type related
files to respective 'default' applications. On linux, where I use the gnome
windows manager, I have the shell alias,
$ which open
open: aliased to xdg-open
to try to bridge the gap, which just goes to show aliases and scripts that use this same format can be really handy for hiding away toil! I don't know if it's ideal for all CLI tooling but I think this approach is certainly an interesting approach to let people slip in their own functionality and 'rewire' an interface to better suit their needs.