Yes and no.
You could try to depend on hook but that supposes they are installed at the remote locations, and that is not always reliable.
Another way to achieve almost the same effect would be by using a smudge/clean attribute filter driver, but not for a full repo.
(Source: Pro Git book: Customizing Git - Git Attributes)
That way the smudge script is able decode the files, while the clean script would encode them.
Again, that could work for a few sensitive files, not for a full repo.
Off course, those scripts would not be in the repository itself, and would be managed/communicated by another way.
As Alkaline points out in the comments, that idea does not scale for a repo, as the main git maintainer Junio C. Hamano comments back in 2009:
As the sole raison d'etre of diff.textconv is to allow potentially lossy
conversion (e.g. msword-to-text) applied to the preimage and postimage
pair of contents (that are supposed to be "clean") before giving a textual
diff to human consumption.
The above config may appear to work, but if you really want an encrypted repository, you should be using an encrypting filesystem.
That would give an added benefit that the work tree
associated with your repository would also be encrypted.
Even though it does not scale to a full repo, the idea was implemented (3 years later in 2013) with git-crypt, as detailed in Dominic Cerisano's answer.
git-crypt uses a content filter driver (implemented in cpp, with commands.cpp setting up your .gitattributes with the relevant smudge and clean filter commands).
As any content filter driver, you can then limit the application of git-crypt to the set of files you want, in the same .gitattributes file:
secretfile filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt
As mentioned in the README:
git-crypt relies on git filters, which were not designed with encryption
in mind.
As such, git-crypt is not the best tool for encrypting most or
all of the files in a repository.
Where git-crypt really shines is where most of your repository is public, but you have a few files (perhaps private keys named *.key, or a file with API credentials) which you need to encrypt.
For encrypting an entire repository, consider using a system like git-remote-gcrypt instead.
(see more at spwhitton/ tech/ code/ git-remote-gcrypt, from Sean Whitton)
