aboutsummaryrefslogtreecommitdiffhomepage
path: root/README.rst
Commit message (Collapse)AuthorAge
* use stronger language regarding gitception/sftp vs. local/rsyncSean Whitton2022-08-21
| | | | Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
* support more standard rsync URIsJoey Hess2021-01-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* shorten and tweak docs and outputSean Whitton2020-07-24
| | | | Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
* rename new config keySean Whitton2020-07-24
| | | | Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
* git config to request abort if --force not passedJay Colson2020-07-24
| | | | | | Default to emit a warning if the git config flag is not set. Signed-off-by: Jay Colson <jay@karma.net>
* generalise GNU/Linux installation instructionsSean Whitton2020-05-11
| | | | | | | | 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>
* Add git-config option to set rsync put flagsTravis Chen2020-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* GCRYPT_FULL_REPACK usagelegrostdg2019-03-03
|
* tweak wording in Ulrike's patchSean Whitton2018-07-24
| | | | Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
* Document connectivity issue error messageUlrike Uhlig2018-07-24
| | | | | | | | | 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>
* rewrite descriptions of rclone backend in READMESean Whitton2018-04-28
| | | | Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
* Add support for several cloud storage remotes using rcloneBeren Minor2018-04-28
| | | | | | | | | | 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>
* add known issuesSean Whitton2018-03-09
|
* consistent capitalisation for section headersSean Whitton2018-03-09
|
* improve first section of manpageSean Whitton2018-03-09
|
* add note about non-standard rsync URIsSean Whitton2018-03-09
|
* add year I became maintainerSean Whitton2018-03-09
|
* avoid comma spliceSean Whitton2018-03-09
|
* fix note about performanceSean Whitton2017-04-05
| | | | | Only the rsync:// backend performs incremental pushes. The sftp:// backend is no better than gitception.
* tweak install.sh instructionsSean Whitton2017-02-19
|
* fix typos & formatting errorsSean Whitton2017-02-19
|
* drop "Note to users of GnuPG version 2"Sean Whitton2017-02-19
|
* tweak credits sectionSean Whitton2017-02-19
|
* split installation instructions out of quickstartSean Whitton2017-02-19
|
* add apt-get installation instructions to READMESean Whitton2017-02-19
|
* tweak note about performanceSean Whitton2017-02-19
|
* re-order git-config optionsSean Whitton2017-02-19
|
* drop strongly-worded request for testingSean Whitton2017-02-19
| | | | git-remote-gcrypt is stable and in maintenance-mode
* add authors and maintainers to READMESean Whitton2017-02-19
|
* add a note about performanceSean Whitton2017-02-19
|
* add "Note to users of GnuPG version 2" to manpageSean Whitton2016-07-04
|
* GCRYPT_GPG_ARGS env var -> gcrypt.gpg-args confSean Whitton2016-07-04
|
* implement GCRYPT_GPG_ARGSSean Whitton2016-01-17
|
* changelog entry for version 1.0.0!Sean Whitton2016-01-17
|
* added gcrypt.publish-participants configurationJoey Hess2014-07-15
| | | | Fixes https://github.com/blake2-ppc/git-remote-gcrypt/issues/9
* improve docsJoey Hess2013-09-19
|
* --check option to see if a repo exists and can be decryptedJoey Hess2013-09-19
| | | | | | | | 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.
* add remote.<name>.gcrypt-signingkey configJoey Hess2013-09-17
| | | | | | | | | | | | 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.
* README: Don't mention keyring files, it's not relevant anymore0.20130908root2013-03-12
|
* Add license header and the text of the GNU GPLroot2013-03-03
|
* Edit wording in READMEroot2013-01-21
|
* README: Fix to use `remote id`root2012-11-29
|
* Update license textroot2012-11-16
|
* Fix markup of Repository Format sectionroot2013-01-03
|
* Edit READMEroot2013-01-20
|
* Organize the README in a neat way, putting extra info in the Notes chapterroot2013-02-14
|
* Edit the summary of the repository format/processroot2013-02-14
|
* Tone down the development version warningsroot2013-02-14
| | | | | We have now implemented the usability changes (No fragment in repository URL, and default encrypt-to-self), so no big changes planned.
* Use a shorter, simpler repo ID since users will see it (occasionally)root2013-02-14
|
* Update README for remote.<name>.gcrypt-participants and default simple moderoot2013-02-14
|