Or, how Hashrocket displays pair programming gravatars on github.
The Peculiar Problem of Pairs
At Hashrocket, we pair program all the time. We also use git exclusively for source control. This presents a problem: git only supports one “commiter,” but we’d like to give credit to both developers. Here’s how we hacked it.
Author vs. Committer
First, a bit of background: git does support the notion of an “author” as distinct from a “committer.” This feature handles the situation where some external third-party developer has submitted a patch to a source maintainer. The maintainer, as the authoritative and github-credentialed “committer,” can commit the changeset for the external developer, who is set as the “author.” Both the author and the committer are recorded in the commit data.
We did think about setting one pair developer as the author, and the other as the committer. But, then we thought of something we think is even sexier.
Set the Pairs in the Author Fields
Unfortunately, git only supports one “author” as well. But, the author fields do provide us a workable place to hack in our pair attribution solution: we concatenate and store both pair developers usernames in the those author fields. In the BASH shell, that goes a little something like this:
bash$ export GIT_AUTHOR_NAME='Jon Larkowski and Tim Pope' bash$ export GIT_AUTHOR_EMAIL=dev+l4rk+tpope@example.com
The convention we use for GIT_AUTHOR_EMAIL is the form: dev+pair1+pair2@example.com where “dev” is short for “developer.” dev is just an email alias that goes to every developer at Hashrocket. The pairs are added in alphabetical order by github username. We hack our usernames into the email address using the “plus-notation” feature of email addresses.
Configure the Committer
Committer for a Developer’s Laptop
As for the committer field, it’s just the developer whose machine you’re pairing on. This allows us to tell which user this commit came from, while still indicating the pair authors. Also, it allows us to simply use that developer’s github credentials for pushing up changes. So the git log --pretty=full after a commit looks something like:
commit 3eb7b3a155f11e56cf406f2b09dc2fd98e92b532
Author: Jon Larkowski and Tim Pope <dev+l4rk+tpope@example.com>
Commit: Jon Larkowski <jon@example.com>
Ebony and ivory, live together in perfect harmony.
Committer for a Shared Pairing Workstation
We do have one twist on the committer. More and more, we’re using communal desktop machines at Hashrocket. We have a couple Macs Pro and a couple Macs Mini (I assure you, those are the proper irregulars plural, look it up). On these shared machines, we name the committer after the machine’s name. This allows us to know which machine a commit came from, but it’s not attached to any particular developer’s name.
bash$ git config --get-regexp user\.* user.email dev+some_workstation@example.com user.name Some Workstation
Also, note that the shared development workstation will need to have its own public key registered on github, under your organization's main github account, not your own personal one.
github & Gravatar Photos
github displays a Gravatar photo next to a username when displaying commit information. This helps add to the “social” feel of github.
Single Developer Gravatar Photo
For you as a lone developer, github just looks up that gravatar based on the email address you gave github when you signed up.
Developer Pair Gravatar Photo
Now for a pair, we need a unique email address that github can use to look up a photo on gravator. This is where our pair developer email address convention comes into play. We just add that dev+pair1+pair2@example.com as a new email address under our main corporate gravatar account, which is maybe signed up under info@example.com for instance.
Gravator lets you have as many email addresses as you one under one main umbrella account. It’s a bit spammy, in that every developer will receive a gravatar confirmation email whenever a new pair permutation signs up. But, that sounds like a “First World problem,” if I ever heard one.
Say, “Cheese!”
We typically just snap our pair photos using Photo Booth.app, since we’re likely pairing at that very moment on a Mac with a built-in iSight camera. Oh, and since we’re picky, we make sure that pair1 is on the left and pair2 is on the right of the photo.
Hitch
Setting git environment variables by hand every time you switch pairs could get tedious. Ro and Les wrote a little gem called “Hitch” that makes this easy.
Install it with:
sudo gem install therubymug-hitchTo set it up, follow the prompts and answer the questions:
hitchrcWhen you start pairing with someone, just call:
hitch your_pairs_github_usernameTo code solo:
unhitchTo pick from the list of your previous pairs:
hitch -iJust running hitch, with no arguments, will tell you who you are pairing with. Pro tip: Add it to your bash profile to see it when you start a shell.
vim, i.e.
:!hitch github_username
Hardcore BASH Scripting Action
Here's a BASH script that accomplishes the same thing as hitch.
To set up a pair:
bash$ pair fry benderBender Bending Rodriguez and Philip J. Fry
To enter a pair that's not a declared variable at the top of the script:
bash$ pair fry hypnotoad="All Hail the Hypnotoad"Philip J. Fry and All Hail the Hypnotoad
To persist a pairing, even between shell invocations:
bash$ pair -w zoidberg benderBender Bending Rodriguez and Dr. John Zoidberg
Use pair with no arguments to see who's paired. Use pair -w with no arguments to clear a persistent pairing.



11 comments:
Genius solution. I love how you guys hacked this up
Yeah, cool solution to the problem.
That's some cool stuff. I loved the plurals reference. Ha!
Thanks for the post Lark! :-)
Fantastic idea, guys. Was pairing just recently and not sure how to handle the author issue. Looking forward to trying it out.
i definitely enjoy all your posting way, very useful,
don't quit and keep writing since it simply very well worth to read it,
impatient to looked over a lot more of your own writing, thanks ;)
Hey, thank you so much for sharing this. You hashrocketers are fucking awesome!
I like this approach and we have been using it at Cubox. However... I'm concerned about each pairing station's private key being widely available to all developers.
Yes, we trust each other. But it can happen that at some point someone leaves the company. It's quite easy to remove that developer's key from github. But it would also require to replace all pairing station's keys too, just in case he/she copied all those keys too and wants to do some "harm" (I know git reset solves it, but anyway).
Only way I can think of to make this a little bit easier is to use the exact same key on all pairing stations instead of having different ones. That way we only need to remove/revoke one key, regenerate and redistribute a new key.
Any better suggestions?
@oboxodo I like your approach of having One Key to Rule Them All. That does make things easier. I think we had considered doing that as well. But we just used automated scripts for hiring and firing to credential many people/machines.
Great, I'm gonna try this at work.
@dgh Thanks, hope it works out for ya. I'm still happily using the hitch gem.
Post a Comment