Git Tools

On a recent commute I mulled over the various tools I use to make git, the popular distributed version control software, easier to use and more powerful. Here's a round up of what I use, or find interesting.

gitconfig - anything you do with the git config command can also be placed in a .gitconfig runtime configuration file in your home directory. My main use case is aliases that save me a ton of typing. Simple shortcuts like "c = commit -m" are an obvious starting point. But git also has several commands with multiple, handy flags; for instance, my "sweet-looking but concise logs" alias is "l = log --pretty=oneline -n 20 --graph --abbrev-commit". I do not want to memorize and type that monster, not once, not ever. My entire .gitconfig can be found in my dotfiles repo.

gitsh - an interactive shell for git. If you're running a bunch of git commands in a row, enter gitsh & run them without typing "git" over & over. This can be very useful as git commands tend to come in waves; "oh I need to commit these final changes, rebase, checkout master, & then merge this feature branch" is a common workflow, for example. Gitsh also displays repository information—the current branch & working directory status—in its prompt.

hub - a command-line tool for interacting with GitHub. I don't use this because it wouldn't gain me a whole lot of efficiency but I bet hub would be invaluable if you're an active GitHub user.

js-git - an interesting project to implement git in client-side JavaScript with support for various browser storage APIs. Could feasibly bring git into environments like Chromebooks, where one doesn't have command-line access but could still benefit from version control.

Sublime Text Packages

I use Sublime Text as my main editor & these two packages are great in terms of git integration.

Git - this package is essential if you're working in Sublime Text. It gives access to all the common git commands—add, commit, diff, log—right in the command palette. You never have to leave your editor to access version control, you can stay in a single context & do everything you need. It's a huge boon to productivity. I use "Quick Commit" (adds and commits the file I'm currently viewing) all the time. I bet roughly a third of my commits are through that single convenience method.

GitGutter - highlights lines that have been changed, added, or deleted in the file you're viewing with coloring in the gutter. You can select from a few different styles of coloring. This is a small nicety most of the time but can be of great assistance when returning to a project that has a dirty working directory or stashed changes which you've forgotten.

Start-Up Thinking Is Inappropriate for Libraries

tl;dr — if you believe your institution is a social necessity, start-up thinking is a terrible approach.

A recent conversation with a friend who has worked in the start-up space brought up Brian Mathew's "Think Like a Start-Up" white paper and some unresolved issues I have with it, never publicly articulated. See also: The Marketing Unproblem of Libraries.

#Fail

Most start-ups fail. Start-ups are praised for their agility, their ability to solve problems, but not for their longevity. If you believe in the worth of libraries as institutions, I'm guessing you don't want 75% of them to go under. It's unfathomably, eye-rollingly ironic that Mathews starts his white paper with doomsaying about the sustainability of academic libraries and then offers transient organizations as a model for survival. I can't even.

Trying to flip this fact later in the white paper does little to assuage my concerns. Noting the failure-prone nature of start-ups is not simply some snarky observation; it speaks to irreconcilable differences between how start-ups are run & how are libraries should be run. If you want your library to be around next year, next decade, next century, you probably don't want to emphasize risk-taking. Long-term thinking might be more suitable. You probably don't want to be a technological solutionist. Heck, you probably don't want to rely on the assumption that you only need to serve a population with access to certain technologies. Making an iPhone app is not enough. Making any app is not enough. Being a community-driven organization just might be enough.

It's also worth mentioning start-up culture has its own atrocities. It's hostile to women.* It's hostile to people of color. They're just generally not the type of organization socially conscious people probably want to work for, not that there aren't exceptions to this generality. I find it intolerable to valorize start-up culture while its downsides go unmentioned.

On Choosing Appropriate Proxies

I envision a rejoinder that libraries should praise & emulate the agility & innovativeness of start-ups, focusing on those attributes rather than their ephemerality. Leaving aside the fact that this straw-person argument is basically "but if you only look at the good things start-ups are good," it hints that start-ups are a poor proxy for what we actually want to talk about. I despise poor proxies. They muddle the debate & obscure the underlying issues. To use my favorite example: when we use age as a proxy for technical savvy, we not only discriminate against older folks but overestimate the abilities of the young. So let's discuss "libraries should be agile & innovative," not "libraries should think like start-ups."

But that's a lame tag-line right? And tag-lines are important. It's catchy, "Think like a Start-Up." But if it's so misleading as to be positively counterproductive, it should be ditched.

Exeunt

Finally, there's perhaps a tension in that start-ups are capitalist institutions par excellence & modern libraries** typically follow a more socialist, resource-sharing approach. But that's too much to go into here & I haven't thought about it enough.

In general, there are virtually no similarities between what libraries should be(come) & what start-ups are. Mic drop.

Notes

* There are numerous examples or articles I could have linked to here but Ashe Dryden's is particularly apt. If you think this statement is contestable, leave a comment & I can cite additional instances of hostility.

** Obviously "social libraries" like Benjamin Franklin's Library Company of Philadelphia (unnecessary emphasis mine), where only subscribed members could access the collection, aren't following a very socialist model. These are less common in America today than tax-funded public libraries, for instance.