There's a tradeoff. When the path is hardcoded, it's guaranteed that
git-crypt will be found no matter where you run git or what your $PATH is.
On the other hand, hardcoding means that things break if git-crypt changes
location, which could easily happen if you copy a repository to a different system
(see https://github.com/AGWA/git-crypt/issues/71 for example).
In hindsight, I think this was a bad tradeoff. Now, if git-crypt is
invoked as a bare filename (no slashes), the bare filename is placed
in .git/config under the assumption that it can be found via $PATH
(this assumption will be true as long as git-crypt wasn't resolved via
a relative path in $PATH). This logic was already being used on
non-Linux OSes and it seemed to work fine.
Rename HAS_DOCBOOK option to ENABLE_MAN.
Allow xsltproc to fetch the Docbook stylesheet from the Internet if it's
not installed locally. This will hopefully make it easier for folks
to build the man page.
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.
