Josh Rabinowitz

get `arch` builds working again, because they are not

1

See https://github.com/sobolevn/git-secret/runs/7564903813?check_suite_focus=true Ends with: ```` checking keyring... downloading required keys... :: Import PGP key 139B09DA5BF0D338, "David Runge "? [Y/n] checking package integrity... :: File /var/cache/pacman/pkg/libcap-2.65-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted...

WIP for #135 Currently just shows problem * analysis shows error is happening in `gitignore_add_pattern`'s call to `_gawk_inplace` when running `git-secret-init` * This is output from `bash -x` on `git-secret-init`...

As per #760, we could help users avoid issues when mixing different versions of gnupg on the same repo. @sobolevn suggests writing a '.gitsecret/VERSION file with gpg version', and @FanchenBao...

Re: https://github.com/sobolevn/git-secret/pull/783/files (although code now uses file descriptor 5) See for example https://stackoverflow.com/questions/41603787/how-to-find-next-available-file-descriptor-in-bash I'm not sure if this can actually be an issue or not for git-secret

As per #874, if`git rev-parse --is-inside-work-tree` fails in _is_inside_git_tree(), we could show the error message returned.

if passed files, clean options to git-secret hide should only delete the corresponding files

1

When looking into #833, I discovered that * `git-secret-hide -c file.txt` will remove all encrypted version of hidden files, even though filename specified - _this should be fixed_. Edit: my...

release 0.5.1 for all platforms except alpine, so we can pass self-tests with the release

2

Idea: remove support for alpine packages from git-secret and release 0.5.1; then when we resolve the alpine issue(s) we release a new 0.5.2 @sobolevn

Gnupg FAQ explains a lot about Gnupg, and we should consider linking to it in the docs. The FAQ is here: https://www.gnupg.org/faq/gnupg-faq.html

explain src/commands src/_utils/ tests/ man/ Makefile targets a little about github integration