`git rm --cached` vs `git reset`

[ljm42]

When I add existing files to Transcrypt via .gitattributes: config/** filter=crypt diff=crypt merge=crypt

Then git commit on other files results in this message:

Transcrypt managed file is not encrypted in the Git index: config/secret.txt

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 -- config/secret.txt
    git add config/secret.txt

Except that git reset has no effect. In order to get past this I have to do this:

    git rm --cached config/secret.txt
    git add config/secret.txt

Would it make sense to change the error message to use git rm --cached instead of git reset?

[jmurty]

Thanks for the suggestion, this is done in 331b4afa859df38969aa0689a9a0001e2525f9e8

[fortysix2ahead]

That does not work for me in transcrypt 2.2.3. I get the same message as outlined above, but when I follow the directions it has no effect. Transcrypt still complains that the file was staged using an unsupported tool.

[jmurty]

Hi @fortysix2ahead can you describe in detail when and how you added the problem file to the Git index, and when you added a rule for that file to .gitattributes?

You can check whether the file staged in the index is really encrypted or not by running commands like:

• git diff --staged to show the file contents, or changes, as they were in the working copy
• git diff --staged --no-textconv which should no longer show the plaintext file contents, just mention a binary file.

If transcrypt's pre-commit hook is getting it wrong and the staged file really is properly encrypted, you can work around the problem by disabling the hook so you can commit the file, then (ideally) re-enabling it for safety. E.g:

mv .git/hooks/pre-commit .git/hooks/pre-commit.bak

# Commit your secret files

mv .git/hooks/pre-commit.bak .git/hooks/pre-commit

[fortysix2ahead]

@jmurty as far as I can remember I used lazygit (which is obviously a non-supported tool) first to stage the file. Afterwards I edited .gitattributes. Interestingly, I did a hard reset for testing, discarding all changes and then staged the file again using git add and still got the same message from transcrypt.

--staged and --staged --no-textconv do not show any difference, both show the filecontent unencrypted.

I have the feeling I screwed up my test repo. I'll try more experimenting, maybe I can find out what went wrong.

[jmurty]

Thanks for following up.

It's not so much that problematic tools are not supported by transcrypt, it's more that they don't do the work expected based on settings in the .gitattributes file.

I'm surprised the git diff --staged --no-textconv command is showing the unencrypted file contents after you edited .gitattributes and re-added the file with Git. There's definitely something going wrong there.

The --no-textconv option should show you the data that will be stored by Git on commit, with "binary" meaning data that is encrypted and therefore not human-readable. So it seems like the pre-commit hook is doing its job and preventing you from accidentally committing an unencrypted file. The question is why is the file not being encrypted when you are adding/staging it?

Double-check that your repo has transcrypt configured by displaying the config with transcrypt --display

[jmurty]

If you're experimenting with transcrypt, these commands can be helpful: git show :path/to/file and transcrypt --show-raw path/to/file

They will show you the raw contents of the file as stored in Git. What you want to see for your encrypted files is a bunch of Base64 text starting with U2FsdGVk, that's encrypted data as generated by transcrypt. You do not want to see unencrypted content from these commands, because that will end up pushed as plaintext to your remote.

[fortysix2ahead]

Did a retest from scratch and now it seems to work fine. I got a bad type in .gitattributes and got the message as outlined above, which in my case put me on the wrong trail ...