'git-crypt status' tells you which files are and aren't encrypted and
detects other problems with your git-crypt setup.
'git-crypt status -f' can be used to re-stage files that were incorrectly
staged unencrypted.
The UI needs work, and it needs to also output the overall repository
status (such as, is git-crypt even configured yet?), but this is a
good start.
The active key is now stored in .git/git-crypt/key instead of being
stored outside the repo. This will facilitate GPG support, where the
user may never interact directly with a key file. It's also more
convenient, because it means you don't have to keep the key file
around in a fixed location (which can't be moved without breaking
git-crypt).
'git-crypt init' now takes no arguments and is used only when initializing
git-crypt for the very first time. It generates a brand-new key, so
there's no longer a separate keygen step.
To export the key (for conveyance to another system or to a collaborator),
run 'git-crypt export-key FILENAME'.
To decrypt an existing repo using an exported key, run 'git-crypt unlock
KEYFILE'. After running unlock, you can delete the key file you passed
to unlock.
Key files now use a new format that supports key versioning (which will
facilitate secure revocation in the future).
I've made these changes as backwards-compatible as possible. Repos
already configured with git-crypt will continue to work without changes.
However, 'git-crypt unlock' expects a new format key. You can use
the 'git-crypt migrate-key KEYFILE' command to migrate old keys to the
new format.
Note that old repos won't be able to use the new commands, like
export-key, or the future GPG support. To migrate an old repo, migrate
its key file and then unlock the repo using the unlock command, as
described above.
While making these changes, I cleaned up the code significantly, adding
better error handling and improving robustness.
Next up: GPG support.
