A great article on a few intermediate-level tidbits of knowledge:
At some point, you might find yourself running the same sequence of git operations on a regular basis. It would greatly improve your efficiency to stash these commands into your own Git subcommand.
For example, I could create a script named “git-dustin”:
#!/bin/sh echo "Dustin's subcommand: $1"
Then, I’d save it into /usr/local/bin (in order to be in the path), and mark it as executable. I can then access it as if it were a subcommand:
$ git dustin "test argument"
This is the output:
Dustin, subcommand: test argument
At its simplest, Tig allows you to navigate your Git projects from the console (it internally invokes commands to git). It has nearly all of the browsing functionality of Github while readily running locally. At it’s most-complicated, it looks to be as flexible as Git itself.
The two simplest ways to run Tig (from within our Git project):
- Piping: git log | tig
- Calling directly: tig
In the case of piping, you’re really just benefiting by coloring the output and pumping it through pagination. If you’re going to call Tig directly, the experience will be more interactive. The default “view” is the log.
You can also specify other views:
$ tig -h tig 1.2.1 (Nov 29 2013) Usage: tig [options] [revs] [--] [paths] or: tig log [options] [revs] [--] [paths] or: tig show [options] [revs] [--] [paths] or: tig blame [options] [rev] [--] path or: tig stash or: tig status or: tig < [git command output] Options: +<number> Select line <number> in the first view -v, --version Show version and exit -h, --help Show help message and exit
An example of the commit browser. I’ve clicked on a commit to show its diffs:
An example of blaming: