Internalize transcrypt crypt functions

[apeschel]

At the moment, the crypt functions are initialized and permanently set
to whatever the version of transcrypt the user is using contains. This
means updates to these scripts are never propagated out to existing
users.

This commit moves the crypt functions into transcrypt itself, which
should allow for more transparent updates to the scripts to be
propagated out to users.

[apeschel]

This is meant as a POC as one possible solution to this problem:

Several caveats on this at the moment:

• This has only been quickly and minimally tested, but appears to be functional
• There still needs to be logic added to handle git config drift.

It's still possible for the git config expected by transcrypt to drift over time. There should be some functionality that updates the config to handle drift. Maybe some logic that checks git config transcrypt.version, compares it to the user's transcrypt version and updates the config if there's the user is using a newer version?

[apeschel]

Related to #72

[apeschel]

This is just one potential approach, another option is to check git config transcrypt.version on every run, and rerun a subset of save_configuration if the user's transcrypt version is newer.

[apeschel]

It may also make sense to have something like a .transcrypt directory that is saved in the repository, which could save the helper scripts, but also allow them to be consistent between users.

[elasticdog]

I'll have to give this one some thought...the original intention was that you wouldn't have to keep transcrypt installed after the repository is configured and the filters would still work. If you want to ensure a consistent version, you can always just check the script into your repo and share that version across users.

The lack of ability to update things automatically is a legitimate concern, but that also means we don't have to bake in knowledge of version checking and compatibility, which could be complex. Breaking changes have only happened once, and it was a major release (2.x) with very explicit instructions on how to handle it. Even if the filters updated transparently, you'd still have to coordinate transcrypt upgrades across users for the repo to be functional for everyone.

[apeschel]

@elasticdog Having the scripts be part of the repository is also a good solution, but with their current home under .git/crypt, there's no way to actually include them in the repository. Just moving them to a crypt directory in the git project root or something would be a good alternative.

[jmurty]

Hi @apeschel I shamelessly stole your approach in this PR with mine in #112 which I have just merged. I didn't find this PR at the time to credit you properly, but ended up re-implementing much of what you proposed here.

A key difference of #112 to this one is that the entire transcrypt script as run at init time is copied into the Git crypt/ directory and the clean/smudge/etc filters refer to that copied file from that point on, as opposed to referring to the system-installed transcrypt version.

I believe the #112 works against your main intention here, which was to make it easier to update transcrypt in repositories by just updating the system-wide transcrypt version.

On the bad side, you still need to manually --upgrade each repo to update transcrypt's behaviour or fix bugs.
On the good side, upgrading the system-wide transcrypt version won't mysteriously change behaviour for all init-ed repos, and uninstalling the system-wide transcrypt won't break everything.

[jmurty]

The work already merged in #112 and further improvements pending in #114 will internalise what were many transcrypt-installed scripts into multiple references to the single, original script that is copied into the Git directory on installation.

[apeschel]

@jmurty Looks like a big improvement, and it should fix the issue we were hitting with different users having different version of the crypt functions, even when they had the same version of transcrypt. Thanks!