GitUp does not work with clean/smudge filters?

[mrmachine]

https://github.com/elasticdog/transcrypt is a project that transparently encrypts files within a git repository, using git's clean/smudge filters. This works as expected:

~/test ❯❯❯ git init
Initialized empty Git repository in /Users/tailee/test/.git/
~/test ❯❯❯ transcrypt -y
The repository has been successfully configured by transcrypt.
~/test ❯❯❯ echo 'sensitive_file  filter=crypt diff=crypt' >> .gitattributes
~/test ❯❯❯ echo foo > sensitive_file
~/test ❯❯❯ git add .gitattributes sensitive_file
~/test ❯❯❯ git commit -m 'Add encrypted version of a sensitive file'
[master (root-commit) 392ca6f] Add encrypted version of a sensitive file
 2 files changed, 2 insertions(+)
 create mode 100644 .gitattributes
 create mode 100644 sensitive_file
~/test ❯❯❯ transcrypt -s sensitive_file
==> sensitive_file <==
U2FsdGVkX19CZfq6z9fVIC8B5uHWMBIAE3lMHSs8wJk=

If I use GitUp just to commit (after adding the file to be encrypted via CLI), it also works:

~/test ❯❯❯ git init
Initialized empty Git repository in /Users/tailee/test/.git/
~/test ❯❯❯ transcrypt -y
The repository has been successfully configured by transcrypt.
~/test ❯❯❯ echo 'sensitive_file  filter=crypt diff=crypt' >> .gitattributes
~/test ❯❯❯ echo foo > sensitive_file
~/test ❯❯❯ git add .gitattributes sensitive_file
~/test ❯❯❯ gitup
~/test ❯❯❯ transcrypt -s sensitive_file
==> sensitive_file <==
U2FsdGVkX19D6HIiAQfIwLpD0E9jda/l4ib84wuVNgY=

But if I use GitUp to add (and commit from CLI), it doesn't work:

~/test ❯❯❯ git init
Initialized empty Git repository in /Users/tailee/test/.git/
~/test ❯❯❯ transcrypt -y
The repository has been successfully configured by transcrypt.
~/test ❯❯❯ echo 'sensitive_file  filter=crypt diff=crypt' >> .gitattributes
~/test ❯❯❯ echo foo > sensitive_file
~/test ❯❯❯ gitup
~/test ❯❯❯ git commit -m 'Add encrypted version of a sensitive file'
[master (root-commit) 72b22f5] Add encrypted version of a sensitive file
 2 files changed, 2 insertions(+)
 create mode 100644 .gitattributes
 create mode 100644 sensitive_file
~/test ❯❯❯ transcrypt -s sensitive_file
==> sensitive_file <==
foo

So GitUp is not properly calling the clean/smudge filters when files are staged to the index?

[swisspol]

GitUp does not execute attribute filters: https://github.com/git-up/GitUp/wiki

[mrmachine]

Is that because it can't be done, or just hasn't been implemented (yet)? If the latter, is it likely to ever be implemented?

This makes it very easy to accidentally commit unencrypted secrets if anyone is using GitUp and transcrypt (and probably git-crypt and others), and if we decide to choose transcrypt over GitUp, it still might be likely that a new developer comes along who doesn't know they can't use GitUp and accidentally commits unencrypted secrets.

[swisspol]

In believe it can be done but it's highly unlikely it will ever be implemented.

You will have this problem with any Git tool that doesn't use the Git CLI. You might want to reject pushes server side if they contain unencrypted commits.

[cyborch]

Man, I really liked GitUp. Now I cannot use it after all.

[mrmachine]

@cyborch you can still use it, just do not use it to stage files that depend on clean/smudge filters. Transcrypt has implemented some protection against accidentally committing unencrypted secrets with a pre-commit hook that gets installed when the git repo is initialised (clean/smudge filters configured). This is still not ideal because I love the GitUp experience for staging commits and would love to be able to do that for files that depend on clean/smudge filters.

@swisspol @lucasderraugh Is there still no chance this will ever be implemented?

[lucasderraugh]

It won't be changed on our end unless libgit2/libgit2#3224 is resolved.

[mrmachine]

@lucasderraugh I might be reading it wrong, but is libgit2/libgit2#3224 resolved now? Does this mean GitUp could now potentially be updated to work with clean/smudge filters?

[lucasderraugh]

@mrmachine In theory, yes. I haven't looked at the details of what was changed on libgit's end, but it would probably require some extra work on our end to add in the feature if it is part of libgit2.