Previously, lock/unlock needed to spawn a separate `git check-attr`
process for every single file in the repository (whether encrypted
or not). This was extremely inefficient, especially on Windows.
Now, git-crypt spawns a single `git check-attr` process and communicates
with it over stdin. In a repository with thousands of files, this
results in a speedup of nearly 100x.
This relies on the --stdin and -z options to `git check-attr`, which
were only added in Git 1.8.5 (released 27 Nov 2013). With older versions
of Git, git-crypt falls back to the old and slower code.
This will be useful as we start to gate code on the version of Git that's installed.
A lot of code out in the wild seems to assume that the output of `git version`
is "git version $VERSION", so I'm assuming it's safe for git-crypt to rely
on that too.
If this option is specified, then the GPG users are added even
if their keys are not trusted by GPG.
In addition, if a full fingerprint, prefixed by 0x, is specified,
it is assumed to be trusted, regardless of its trust level in the
GPG trustdb.
When the with-fingerprint option is enabled, the gpg command invoked by
git-crypt to look up a GPG user ID returns a fingerprint for both primary
keys and sub-keys. Previously, this misled git-crypt into thinking that
the user ID matched more than one public key. Now, git-crypt ignores
fingerprints for sub-keys.
Non-files (symlinks and gitlinks (used by sub-modules)) cannot be
encrypted, so we shouldn't try messing with them. This fixes `git-crypt
status` when used on a repository with sub-modules or symlinks when the
path to the sub-module or symlink has the git-crypt attribute (which
can happen inadvertently when using wildcards in .gitattributes).
It will force a lock even if working directory is unclean. Useful
for deconfiguring git-crypt if you've accidentally unlocked with the
wrong key or gotten into a similarly sticky situation.
This will let us run 'git lock' even if no filters are configured.
This logic is more complicated than I would like because running
'git config --remove-section' on a non-existent section results in
a noisy error (with text printed to stderr and an exit code of 128)
instead of a quiet error like the other 'git config' commands.
Previously, git-crypt claimed to support Git as old as 1.6.0 (albeit
with degraded operation). However, this has not been true for some time,
since Git 1.6.0 does not support the --porcelain option to `git status`.
Since Git 1.7.2 was the first version of Git to support filters with
`git blame`, was released almost five years ago (in July 2010), and is
even in Debian Squeeze, it seems like a good minimum version to require.
Starting with Git 2.2.2, `git checkout -f HEAD` no longer checks out
files if their mtimes haven't changed. This causes files to remain
encrypted in the work tree after running `git-crypt unlock`, and to
remain decrypted after running `git-crypt lock`'.
To fix this, git-crypt now figures out what files are encrypted (by
checking `git check-attr` on every file output by `git ls-files`),
touches those files, and then runs `git checkout` on them.
Previously, if you had a .gitattributes file in the root of your
repository that matched `*`, the files under .git-crypt would also be
encrypted, rendering the repository un-decryptable, unless you explicitly
excluded the .git-crypt directory, which was easy to overlook.
Now, `git-crypt add-gpg-user` automatically adds a .gitattributes file
to the .git-crypt directory to prevent its encryption.
IMPORTANT: If you are currently using GPG mode to encrypt an entire
repository, it is strongly advised that you upgrade git-crypt and then
do the following to ensure that the files inside .git-crypt are stored
properly:
1. Remove existing key files: `rm .git-crypt/keys/*/0/*`
2. Re-add GPG user(s): `git-crypt add-gpg-user GPG_USER_ID ...`
