Saw that -- awesome. I rolled something similar where gitcrypt.salt and gitcrypt.pass were stored in a gpg-encrypted file. After cloning, you decrypt once with gpg, then un-smudge all the encrypted files. No more gpg after that.
How does your solution differ? Is the shared gitcrypt.pass gone entirely? Do I potentially need access to a gpg keyring every time I checkout, diff, log, etc?
The few times I've needed to do that I had to proxy the GPG agent connection via socat and through ssh port forwarding, which is not very sane.
Yeah, it's too messy for me. My question was, if ssh-agent can be forwarded, why can't gpg-agent be forwarded? Boy was that a rabbit hole.
It seems the ssh-agent forwarding protocol is specific enough that it couldn't be used for gpg-agent.
Also, while gpg-agent can apparently stand in for ssh-agent when it comes to ssh keys, ssh-agent can't stand in for gpg-agent with gpg keys.
Furthermore, I got the sense that the gpg folks don't even want gpg-agent forwarding either -- too insecure for them.