4 ms·

Thanks for your feedback. It's true that there are still edge cases where the repo can get in an inconsistent state. This is the biggest issue I need to addre

by agwa 13y ago

Thanks for your feedback. It's true that there are still edge cases where the repo can get in an inconsistent state. This is the biggest issue I need to address before the 1.0 release. I should be able to provide commands that will fix up the repo if this happens. And thanks for pointing me in the direction of rebases - I clearly haven't done enough testing with them. As for security, .gitattributes actually does have negation capability (see the article for an example) so you can encrypt the whole repo by default and explicitly whitelist files to not be encrypted. But I must emphasize that if you are encrypting most or all of the files in your repo, git-crypt is not the best tool because as you point out, git filters haven't really been designed for this. Where git-crypt really shines is where most of your repo is public, but you have a few files (perhaps private keys named *.key, or a file with API credentials) which you need to encrypt. I do like your suggestion of a command to check if a file is being encrypted, and plan to implement that.

jrochkind1 13y ago
> Where git-crypt really shines is where most of your repo is public, but you have a few files (perhaps private keys named *.key, or a file with API credentials) which you need to encrypt. Awesome, this is just my use case. I had been not sure if this was actually the use case you were focusing on -- I'd suggest maybe including that exact above sentence in the README, so potential users can understand what you are intending the tool for.
zimbatm 13y ago
I had to go back to the man pages. I think I got stuck at the "Unlike .gitignore, negative patterns are forbidden." and missed that you could unset attributes instead :) In the process I also found `git check-attr` that goes 90% of the way of the `git crypt check` idea. Eg: `git check-attr -a -- path/to/file` will output git-crypt if the file is encrypted. A `git crypt ls` that lists all the encrypted files could be useful too to give more visibility.
- agwa 13y ago
  > In the process I also found `git check-attr` that goes 90% of the way of the `git crypt check` idea. Eg: `git check-attr -a -- path/to/file` will output git-crypt if the file is encrypted. A `git crypt ls` that lists all the encrypted files could be useful too to give more visibility. That's extremely useful - thanks for passing on that info!

by agwa 13y ago

jrochkind1 13y ago

> Where git-crypt really shines is where most of your repo is public, but you have a few files (perhaps private keys named *.key, or a file with API credentials) which you need to encrypt. Awesome, this is just my use case. I had been not sure if this was actually the use case you were focusing on -- I'd suggest maybe including that exact above sentence in the README, so potential users can understand what you are intending the tool for.

zimbatm 13y ago

I had to go back to the man pages. I think I got stuck at the "Unlike .gitignore, negative patterns are forbidden." and missed that you could unset attributes instead :) In the process I also found `git check-attr` that goes 90% of the way of the `git crypt check` idea. Eg: `git check-attr -a -- path/to/file` will output git-crypt if the file is encrypted. A `git crypt ls` that lists all the encrypted files could be useful too to give more visibility.

agwa 13y ago
> In the process I also found `git check-attr` that goes 90% of the way of the `git crypt check` idea. Eg: `git check-attr -a -- path/to/file` will output git-crypt if the file is encrypted. A `git crypt ls` that lists all the encrypted files could be useful too to give more visibility. That's extremely useful - thanks for passing on that info!