Git-Config: Tuning git-log
Increase Your Commit History’s Information Density
In a previous post, we looked at configuring git status to enhance your view of a repository’s present state. In this post, we’ll take a similar look at configuring git log to enhance your view of a repository’s history. The goal here is to simplify and condense its output, giving you more comfortable, readable access to the details that often matter most: the commit hash, for use with commands like git show, and the subject-line of the commit message.
Sometimes I almost feel bad for the git log command. Its default output just can’t compete with perusing a repository’s commit history in the pretty UIs of a service like GitHub or GitLab:
$ git log
commit c897e0084d1e3f54aa09658cbc674a960e8fbba7 (HEAD -> main)
Author: Darth Vader <vader@deathstar.example.com>
Date: Tue Jul 19 14:10:11 2022 -0500
Update known rebel base locations
commit 2a402cb8d4fb3a254242d31beb6f7349bb4f9ef4
Author: Darth Vader <vader@deathstar.example.com>
Date: Tue Jul 19 13:42:05 2022 -0500
Reorder Death Stars and targets
commit 41a0d776916c2d0c4fefd48d43600c954003e75f
Author: Darth Vader <vader@deathstar.example.com>
Date: Mon Feb 28 16:01:23 2022 -0500
Update targets and Death StarsIf you’ve configured Git to use your pager of choice, git log’s output will at least be paged. But paged or not, you can reduce the number of log entries the command returns by passing an integer N to the git log command. For example, git log -1 will show only the most recent commit in the log. And git log -5 will show the last five.
But even if git log’s default output is a little off-putting, there are are still some things you can configure to better suit your preferences as a developer.
Setting a Default Format with format.pretty
Similar to git status, git log is an output-only command. So configuring it with git config or different flags and options is all about changing up its output to your liking.
There are a number of options you can pass to the --format option when you run git log. For example, --format=oneline produces a one-line format:
$ git log --format=oneline -3
c897e0084d1e3f54aa09658cbc674a960e8fbba7 (HEAD -> main) Update known rebel base locations
2a402cb8d4fb3a254242d31beb6f7349bb4f9ef4 Reorder Death Stars and targets
41a0d776916c2d0c4fefd48d43600c954003e75f Update targets and death starsThat format gives you the hash and the first line of the commit message. And if you particularly like that format, you can configure git log to use it all the time: git config -global format.pretty oneline. You’d then need to call git log with -format=medium to see the default-style output.
Abbreviating the Commit Hash with log.abbrevCommit
The problem with the oneline format is, of course, the full 40-character commit hash. Happily, that can be reduced by calling --format=oneline --abbrev-commit:
$ git log --format=oneline --abbrev-commit -3
c897e00 (HEAD -> main) Update known rebel base locations
2a402cb Reorder Death Stars and targets
41a0d77 Update targets and death starsIf you prefer abbreviated commit hashes, you can configure Git to use them as well with git config --global log.abbrevCommit true.
Note that this setting, as well as format.pretty, will affect the commit information displayed with the git show command, too. We’ll look at that command in a future post.
To show the full commit hash with git log or git show, you’ll need to include --no-abbrev-commit
Setting a Fixed Hash-Length with core.abbrev
Whenever Git outputs an abbreviated commit hash, it generates the abbreviation to an auto length based on the number of objects in a Git repository. On a fresh repo that’s just had git init run followed by its initial commit, that'll probably be a 7-character abbreviation, like Vader’s above. By contrast, on mature repositories with tens of thousands of files and commits, you might see abbreviations of 9 or 10 characters, possibly more.
If you’re a little on the obsessive side like me, you might enjoy always seeing the same number of characters regardless of the repository’s contents. A value like 8 or 9 is generally going to be safe. But do be careful with this setting, especially as you go shorter (the minimum length is 4). The more objects there are in a repository, the better the chance that an abbreviated commit might refer to more than one object.
If you prefer your standard length but run into trouble from Git complaining fatal: ambiguous argument 'ab7d2869': unknown revision or path not in the working tree., as it does when the hash you give it is too short (or is mistyped-check that too!), you can always configure the auto value on your large repo: git config core.abbrev auto.
Aliasing Your Preferred Formats
If you’ve read my post about aliasing Git commands, you’ll remember that you can set up a globally available alias by running git config --global alias.XXX, replacing XXX with the command you’d type after invoking git. For example, if you’re a fan of git log --oneline, which is itself a shorthand for --format=oneline --abbrev-commit, but don’t always want it used as it would be with the log.abbrevCommit and format.pretty configurations above, consider creating an alias like lo: git config --global alias.lo "log --oneline". Reaching the pretty one-line output is then a matter of typing git lo.
In this post, you’ve learned how to tune the basic output from git log. You’ve learned how to set its output to a single line, and also how to abbreviate the length of the commit hash git log outputs. And you’ve also seen that sometimes aliasing a preferred set of arguments to a common command can be a ready alternative to configuration values that affect multiple commands across Git.
Karl’s book, Programming WebRTC: Build Real-Time Streaming Applications for the Web, is available from The Pragmatic Bookshelf:
You can participate in conversations about the book and find a discount code on the book’s forum page.
