Add Git pre-commit hook to abort commit with unencrypted files (#31)

[jmurty]

On init, add a pre-commit Git hook script to check Transcrypt-managed files and abort a commit if there is an un-encrypted file staged in the index that would otherwise be committed in plaintext. See related issue #31

This is a safety mechanism to prevent accidental commits of plain text files that have been staged by tools that do not respect or run the .gitattribute filters that Transcrypt needs to do its job.

On commit failure, the error message says how to re-stage the file using Git on the command line:

Transcrypt managed file is not encrypted in the Git index: secret_file

You probably staged this file using a tool that does not apply .gitattribute filters as required by Transcrypt.

Fix this by re-staging the file with a compatible tool or with Git on the command line:

    git reset -- secret_file
    git add secret_file

Because Git hooks work with single scripts only it is difficult to cleanly install and uninstall hook scripts, especially if the user already has a pre-commit hook script in place.

To handle this situation cleanly if naively

• always install a pre-commit-crypt copy of the hook script, which isn't active because it doesn't have the pre-commit file name
• on init, check if the user already has a pre-commit script and instead of clobbering it, print a warning telling the user to manually install the script from pre-commit-crypt
• on uninstall, only delete the pre-commit if it exactly matches pre-commit-crypt file, which would indicate the user had manually edited the pre-commit file.

[jmurty]

This branch is a mess of merges and spurious commits sorry, I should have cherry-picked instead of merging the original v1 changes.

If/when this is merged to master the whole lot should be squashed.

[elasticdog]

Definitely a reasonable implementation for that safety check...thank you for submitting it. Let me know once the merge conflicts have been handled, and I'd be glad to give it another look over.

[elasticdog]

Same suggestion as the other PR, but I think we could use a legit CHANGELOG.

[jmurty]

Hi @elasticdog I have rebased and cleaned up the commits in this PR to make more sense, I think this is ready for review.

Regarding the change log I agree a CHANGELOG file would be best. This is probably something to tackle after dealing with this PR and #76 since the new changeling file should probably include all changes, not just changes specific to these PRs.

[elasticdog]

LGTM!