| Commit message (Collapse) | Author | Age |
... | |
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
The filter directive filters imported upstream tarballs but fails to
filter generated tarballs. It doesn't actually matter because source
format version 3 will ignore a debian/ subdir in an orig tarball.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
We do actually need separate Debian and upstream tags.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
- easier to maintain
- preserves history of Joey's old changes
- permitted by policy
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Since we can expect this software to see use outside of Debian.
closes bluss#12
|
| | | | | | | | |
|
|\ \ \ \ \ \ \ \ |
|
| | |_|_|_|_|_|/
| |/| | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Keyrings managed with gpg2 can contain secret keys whose public part is
unavailable to classic gpg; on the other hand, gpg2 won't see keys
created in gpg after an initial import.
Situations in which error messages like "gpg: error reading key: public
key not found" pop up can now be circumvented by setting the gpg.program
git configuration entry to gpg2.
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
|\| | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Fixes https://github.com/blake2-ppc/git-remote-gcrypt/issues/9
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
set -e causes the xecho to not run if the xgrep fails. At least with OSX's
/bin/sh, which is:
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
This didn't happen on Linux with:
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
Possibly a bug in bash, or an OSX-specific bug. However, disabling set -e
in the subshell seems a good idea anyway.
fixes https://github.com/blake2-ppc/git-remote-gcrypt/issues/15
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
set. Pass --no-tty to gpg in this situation. This is needed to interoperate with the git-annex assistant, which often runs without a controlling terminal, and will in a new version always do so.
Conflicts:
debian/changelog
|
| | |_|_|_|_|/
| |/| | | | |
| | | | | | |
| | | | | | | |
The gcrypt-id is cached to there when running --check
|
| | |_|_|_|/
| |/| | | |
| | | | | |
| | | | | |
| | | | | | |
For unknown reasons, it makes --list-keys sometimes not show fingerprints
of certian keys.
|
| |\ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
https://github.com/jburnham/git-remote-gcrypt
|
| | |/ / / / |
|
| | |_|_|/
| |/| | | |
|
| | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is to allow programs to determine if a repo uses gcrypt, per #6.
Since this program already knows the name of the manifest file and how to
download it and decrypt it, it makes sense to do the check here rather than
in, eg, git-annex.
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is needed by git-annex assistant when it sets up a gcrypt repository,
to ensure that the gpg key it was asked to use to encrypt the repo is the
same key used to sign it. If it's not, pulling from the repo won't work,
due to git-remote-gcrypt's "Only accepting signatories" check.
The user may have a global user.signingkey setting (I do), but be setting
up a different special-purpose key for encrypting their git repo. The
git-annex assistant cannot mess with the global value, so needs this to
override it.
|
| |/
| |
| |
| |
| |
| |
| |
| | |
Otherwise gpg may prompt to verify if we want to encrypt to users who
do not have a defined trust level. But, the participants setting
explicitly listed them, so we know we want to encrypt to them.
closes #3
|
| | |
|
| | |
|
| |
| |
| |
| | |
This reverts commit 26ab69cf54a761207c012685ada7748143322a76.
|
| | |
|
| | |
|
| |
| |
| |
| | |
This reverts commit ef7ad2a0e17446236892c6504b145eb9b2a2a063.
|
| | |
|
| |
| |
| |
| | |
Current upstream does not tag releases.
|