| Commit message (Collapse) | Author | Age |
|
|
|
| |
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Default to emit a warning if the git config flag is not set.
Signed-off-by: Jay Colson <jay@karma.net>
|
|
|
|
|
|
|
|
| |
There isn't much point in listing distro-specific commands with the
same package name in each one, as users of those distros will already
know those commands.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
| |
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
|
|
|
|
|
|
|
| |
Sometimes, git-remote-gcrypt reports 'gcrypt: Repository not found', but
this can be due to all sorts of connectivity issues, or even due to
ssh-agent using a wrong identity. This should at least be in the docs as
it is a very unprecise error message.
Signed-off-by: Ulrike Uhlig <ulrike@debian.org>
|
|
|
|
| |
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>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Only the rsync:// backend performs incremental pushes. The sftp://
backend is no better than gitception.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
git-remote-gcrypt is stable and in maintenance-mode
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes https://github.com/blake2-ppc/git-remote-gcrypt/issues/9
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
We have now implemented the usability changes (No fragment in repository
URL, and default encrypt-to-self), so no big changes planned.
|
| |
|
| |
|