Closed apeschel closed 4 years ago
Hi @apeschel the new --upgrade
command added in https://github.com/elasticdog/transcrypt/pull/86 might help with updates. It's still a manual step, but easier than the uninstall-then-reinit process.
Hi @apeschel I think the new --upgrade
command added to the master branch in ea4aa35c solves the main problem outlined in this issue, so I am closing this specific issue. Please let us know what you think of it if you are able to try the --upgrade
command now on the master branch.
Your idea about "internalising" the various clean / smudge / merge scripts as mentioned here and explored in detail in PR #73 is an interesting one, and something I'm still considering in a broader context where we may need more sophisticated and (hopefully) shared code to handle different versions and capabilities in OpenSSL for #55 etc.
Thanks for contributing!
As far as I can tell, there's no code path that updates the transcrypt scripts stored in .git/crypt, and these files are only updated on initialization.
This is problematic, as changes to these scripts are never propagated out to repositories with transcrypt already initialized.
In https://github.com/elasticdog/transcrypt/commit/c8e4f7279972555282a74c96d7ce48fdbc930083 the method for generating the salt was modified, and is not backwards compatible with the previous method. As a result, users who initialized a repository with transcrypt previous to this commit will be generating different salts, and thus be producing different output than those who initialized the repository after this commit.
For now, the work around is to have all users run
transcrypt -u
and reruntranscrypt
, but this is a very tedious exercise to orchestrate across any organization of any size, and is prone to error.transcrypt should have some facility to update these files automatically and transparently to users.
The most straightforward approach I can think of to fix this in transcrypt is to have it update these files every time it is run in a git repository, but that might be overkill.
A better solution might be to have these files be replaced with either symlinks or simple wrappers that call back out to transcrypt, and add this functionality in as a sub-module to the transcrypt program. This way these functions would always be tied in to the correct version expected by the current version of transcrypt.