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.

That's essentially how the GPG feature works.

git-crypt doesn't use anything called "gitcrypt.salt" or "gitcrypt.pass" though - you might be confusing git-crypt with another project. (I may very well end up renaming git-crypt - it's a way too generic name.)

Cool. I think that's the way to go. If you needed GPG for things beyond the initial checkout, automated git deploys (among other things) would be out of the question.

You might be confusing git-crypt with another project.

Oh, wow, you're right. I'm using a forked version of something called git-encrypt: https://github.com/shadowhand/git-encrypt

This is just a shell script (no compiled code), started about a year before your git-crypt, but interestingly the design is very similar. Both of you are using smudge and clean filters with AES 256.