| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
GET and PUT are meant to exit nonzero on failure, and without this flag, they
always exit zero when rclone is used, even when a file is not found. That
confuses other parts of the code.
Signed-off-by: Nathan Todd-Stone <me@nathants.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for "rsync://user@host/path", which is a valid URI,
and will be parseable by URI parsers, unlike the old "rsync://user@host:path",
which at least some URI parsers will reject due to the ":path" looking
like an unparseable port number. The old nonstandard URI form is also
still accepted.
Note that, the path in the new URI form is not relative to the home
directory, but absolute. This is necessary because "/path" looks like an
absolute directory, and there needs to be a way to specify an absolute
directory. Something like "/~/path" could be added to specify the home
directory, but seems like an unncessary complication.
Note that rsync supports rsync:// URIs itself, but those communicate
with a rsync daemon on its own port, rather than via ssh. gcrypt already
was using rsync:// to denote rsync over ssh, and this does not change
that. So, the url has to be rewritten from "rsync://user@host/path"
to the rsync location "user@host:/path"
I used this test suite while developing the rather complicated sed
expression, to make sure I did not break handling of the old URI form.
set -e
test $(rsynclocation "rsync://host/path/foo") = host:/path/foo
test $(rsynclocation "rsync://host:path/foo") = host:path/foo
test $(rsynclocation "rsync://user@host/path/foo") = user@host:/path/foo
test $(rsynclocation "rsync://user@host:path/foo") = user@host:path/foo
test $(rsynclocation "rsync://user@host/path:foo") = user@host:/path:foo
test $(rsynclocation "rsync://user@host:path:foo") = user@host:path:foo
test $(rsynclocation "rsync://user@host/path:foo/bar") = user@host:/path:foo/bar
test $(rsynclocation "rsync://user@host:path:foo/bar") = user@host:path:foo/bar
test $(rsynclocation "rsync://user@host/path/foo/bar") = user@host:/path/foo/bar
test $(rsynclocation "rsync://user@host:path/foo/bar") = user@host:path/foo/bar
Signed-off-by: Joey Hess <id@joeyh.name>
|
|
|
|
| |
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
|
|
| |
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
|
|
|
|
| |
git-remote-gcrypt is POSIX sh.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
|
|
| |
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
|
|
|
|
| |
Default to emit a warning if the git config flag is not set.
Signed-off-by: Jay Colson <jay@karma.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provide the ability to pass flags to `rsync` when uploading.
There are two ways to set the configuration:
- `gcrypt.rsync-put-flags`
- `remote.<name>.gcrypt-rsync-put-flags`
The flags will be applied to `rsync` during uploading when using the `rsync://`
backend. If `remote.<name>.gcrypt-rsync-put-flags` is set, the flags set in
`gcrypt.rsync-put-flags` will not be applied to the remote `<name>`.
This change also includes documentation.
We have tested with the following configurations:
1. none set
2. `git config gcrypt.rsync-put-flags "--perms --chmod=g+rX"`
3. `git config remote.<name>.rsync-put-flags "--perms --chmod=o+rX"`
4. both (2) and (3)
All local files start with only owner permissions set, and umask is set to 077.
In (1), no change in behavior as before, as expected. In (2), the remote files
have the group permissions set, as expected. In (3), the remote files have the
other permissions set, as expected. In (4), the remote files have the other
permissions set, but do not have the group permissions set, as expected.
Signed-off-by: Travis Chen <travis.chen@everchanging.dev>
|
|
|
|
|
|
|
| |
Otherwise you'll get the error output whenever you push to a new
remote.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
| |
|
|
|
|
|
|
| |
Closes: #914059
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
|
|
|
|
| |
Move it to where the repository format notice used to be.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
|
|
|
|
|
|
|
|
| |
rclone is an open-source command-line too to get and put files to several
cloud storage services that aren't supported by rsync.
git-remote-gcrypt can now push encrypted repositories to any configured rclone
remote using gcrypt::rclone://<rclone-repo>:<folder> URLs.
Signed-off-by: Beren Minor <beren.minor+git@gmail.com>
|
|
|
|
| |
* workaround: skip the '-m 700' on mingw64/32 and msys
|
| |
|
| |
|
|
|
|
|
| |
Based on commit a72eb5d9520a8d7fa23478aeb1c14a14e66c19a2 by Raphaël
Droz's fork -- thanks.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a gcrypt remote is not available, for any reason
(network being down, the drive containing it not being
mounted, etc), pushing to the remote causes a new repository
ID to be created.
Instead, we now fail loudly when a remote is unavailable and
when the remote ID is already set.
https://github.com/bluss/git-remote-gcrypt/issues/20
(cherry picked from commit b46d48af15e0f8b89f2666aff2c045c9306305d6)
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
|
|
|
|
|
| |
We need to remove this since git handles ssh:// URLs already. With this
change, we now use the git backend for these.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Using a standard directory for temporaries buys us performance when the
user wants it (has configured tmpfs for /tmp) and configurability
(accepts TMPDIR=).
Moving /pack to a temporary directory gives safe concurrent remote
repacks.
|
| |
|
|
|
|
|
|
| |
There should be no difference if we use 32 random bytes or more, since
GPG's longest symmetric key is 32 bytes, but to just remove any doubt we
use a longer random passphrase.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Use echo_kill for when echo_die is not enough.
|
| |
|
| |
|
| |
|
| |
|