мерзавец шифрует/дешифрует удаленные файлы хранилища в то время как нажатие/получение по запросу

И да, и нет.

Вы можете попробовать зависеть от хуков, но это предполагает, что они установлены в удаленных местах, а это не всегда надежно.

Другим способом добиться почти такого же эффекта было бы использование драйвера фильтра атрибутов smudge/clean, но не для полного репо.

^{(Источник: книга Pro Git: Customizing Git - Git Attributes)}

Таким образом, скрипт smudge сможет декодировать файлы, в то время как чистый скрипт будет их кодировать.
Опять же, это может сработать для нескольких конфиденциальных файлов, но не для полного репозитория.

Конечно, эти скрипты не будут находиться в самом репозитории, и будут управляться/передаваться другим способом.

Как Alkaline указывает в комментариях, эта идея не подходит для репозитория, как заметил главный сопровождающий git Junio C. Hamano ещё в 2009 году:

Поскольку единственный смысл существования diff.textconv заключается в том, чтобы позволить потенциально убыточное преобразование (например, msword-to-text), применяемое к пре- и пост-изображению пары содержимого (которое должно быть "чистым") перед тем, как предоставить текстовое перед тем, как отдать текстовое содержимое на потребление человеку.

Приведенный выше конфиг может показаться работающим, но если вы действительно хотите иметь зашифрованный репозиторий, вам следует использовать шифрующую файловую систему.
Это даст дополнительное преимущество в том, что рабочее дерево связанное с вашим хранилищем, также будет зашифровано.

Несмотря на то, что эта идея не подходит для полного репозитория, она была реализована (3 года спустя в 2013 году) с помощью git-crypt, как подробно описано в ответе Доминика Серисано.
git-crypt использует драйвер фильтра контента (реализованный на cpp, с commands.cpp настройкой вашего .gitattributes с соответствующими smudge и clean командами фильтра).
Как и любой драйвер фильтра содержимого, вы можете ограничить применение git-crypt набором нужных вам файлов в том же файле .gitattributes:

secretfile filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt

Как упоминается в README:

git-crypt полагается на git-фильтры, которые не были разработаны с учетом шифрования. в виду.

Поэтому git-crypt не является лучшим инструментом для шифрования большинства или всех файлов в хранилище.
git-crypt действительно сияет там, где большая часть вашего репозитория публична, но у вас есть несколько файлов (возможно, закрытые ключи с именем *.key, или файл с учетными данными API), которые вам нужно зашифровать.

Для шифрования всего репозитория лучше использовать систему вроде git-remote-gcrypt вместо этого.

(подробнее на spwhitton/ tech/ code/ git-remote-gcrypt, от Шона Уиттона)