| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* local, rsync, ssh, sftp repositories are still compatible
* gitception/git backend repositories are not compatible and need to be
deleted and recreated
* Put manifest in a static location, so we don't need #fragment in the URL
* Record repository ID for each remote, and warn if it changes.
* Use SHA-256 by default but allow reading SHA-224-identified packfiles
* The URL #fragment identifies branch to use when using the git backend
|
| |
|
| |
|
| |
|
| |
|
| |
|