Closed impredicative closed 3 years ago
It's not a matter of performance, but rather usability. git-crypt's approach of using Git filters imposes a rather high usability tax. It's not possible to give a precise number for when the usability tax becomes too high, but the use cases I envisioned had <10% of the files in a repo be encrypted. Perhaps others can chime in if they're using git-crypt with a greater proportion of encrypted files, but to be honest I am really skeptical git-crypt is the best tool for the job if that's your use case.
What is the specific usability cost or blocker preventing use >10% or approaching 100%?
gitattributes files are finicky and hard to get right. There is currently no merge driver (this could be fixed but the PRs so far have bugs) so git-crypt can't handle merge conflicts of encrypted files. There are probably other annoyances. Based on bugs filed over the years, people appear to have more trouble the farther they stray from git-crypt's intended use case.
I should also mention the security cost - as explained in the README, filenames, file sizes, and commit messages are not encrypted. This is unavoidable if you want the repo to be public except for a handful of files. Once you reach 100% encrypted, this is a pointless cost to pay.
Noted. I looked at git-remote-gcrypt, but it doesn't seem like a good option if it'll always upload everything at each push, as I think it does. That won't scale at all.
In addition to git-crypt, I will also consider a simple user-space encrypted filesystem which I can check-in to git.
For a given repo, how many files and how many bytes would git-crypt scale to? What would be too many?