I know this will sound grumpy, but I’ve got a much simpler suggestion:
This eliminates whole classes of lawsuits for you, and makes your Git configuration wonderfully simple: you just have a main dotfile, plus a computer-specific override, which likely won’t exist for any personal boxes and will exist for your work laptop. Do that, and this entire blog post devolves into literally one line that provides work-specific overrides for your personal config.
It’s not grumpy, it’s what you should be doing.
Your work computer is very likely not your property. It’s also very likely your employment contract does not guarantee you privacy on that machine. So putting private SSH keys on your work machine seems like a bad idea. Furthermore, doing personal projects on them is also seems like a bad idea. As stated, mixing work and personal machines is flirting with lawsuits.
Making this kind of setup is following DRY way too slavishly. Accept the fact that work and personal computing time shouldn’t mix and keep two configurations.
I use a VM for personal stuff on my work machine, and work stuff on my personal machine. It’s not great, but it’s certainly better than not making the distinction.
I simply leave out the email address from the global gitconfig file (that’s synced between computers), and will be prompted by git to provide it the first time I want to commit for every new project I clone.
Assuming I have different personal and work git server hosts, I have pre-commit and post-checkout hooks which automate most of this like so:
ORIGIN="$(git remote get-url origin 2>/dev/null)"
if expr "$ORIGIN" : '.*megacorp\.com' > /dev/null ; then
# Setting repo email to work email
git config --local user.name 'Worker Drone'
git config --local user.email 'firstname.lastname@example.org'
# Setting repo config to personal email
git config --local user.name 'Personal User'
git config --local user.email 'email@example.com'
My configuration is the same between work and personal. In fact, the work machine’s ~/.gitconfig even has my personal email configured.
In the directory I use as the root for all the work projects, I have a direnv .envrc that sets GIT_AUTHOR_EMAIL and GIT_COMMITTER_EMAIL.
I use the same dotfiles for home and work where different configurations like the email address used in ~/.gitconfig are applied through a simple .patch file: https://github.com/klingtnet/dotfiles/blob/master/Makefile#L19
Ok, I didn’t know that git 2.13 extended includes allowing conditional configuration. Nice stuff, but requires organizing specific directory layout for your repos, which may be already there, but not necessarily splitted between personal and work-related ones, so it may not suite everyone.
So far I was doing it by having same (personal) ~/.gitconfig everywhere and additional ~/.gitconfig.local, where my personal e-mail was overridden by corporate one. ~/.gitconfig includes ~/.gitconfig.local unconditionally, but I have a small script called gitcon, so I could easily change whether local version should be included (gitcon local 1) or not (gitcon local 0, which simply comments out include entry in ~/.gitconfig).
gitcon local 1
gitcon local 0