mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

update for new rclone gitannex command

Browse source
This commit is contained in:
Joey Hess 2024-03-26 13:48:43 -04:00
parent a3a09f20e9
commit 962da7bcf9
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 45 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

8
doc/forum/New_external_special_remote_for_rclone/comment_3_4412a5a25ac933de71772afd23cd66bd._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2024-03-26T17:38:07Z"
content="""
See [[todo/external_special_remotes_not_using_git-annex-remote_in_name]]
for possible changes in git-annex related to this.
"""]]

9
doc/special_remotes/rclone.mdwn
View file

@ -24,7 +24,14 @@ the time of writing, this includes the following services:
* Yandex Disk * Yandex Disk
* The local filesystem * The local filesystem
That list is regularly expanding. git-annex supports all of those through That list is regularly expanding.
git-annex supports all of those through
the use of the [rclone special remote](https://github.com/DanielDent/git-annex-remote-rclone). the use of the [rclone special remote](https://github.com/DanielDent/git-annex-remote-rclone).
Alternatively, rclone recently gained support for being used as a special
remote on its own, without needing installation of the above program.
For documentation on using rclone that way, see the output of
`rclone gitannex` or [here](https://github.com/git-annex-remote-rclone/git-annex-remote-rclone).
See their documentation for more concrete examples. See their documentation for more concrete examples.

29
doc/todo/external_special_remotes_not_using_git-annex-remote_in_name.mdwn Normal file
View file

@ -0,0 +1,29 @@
rclone now supports being run as a git-annex special remote natively
see <https://github.com/rclone/rclone/pull/7654>. "rclone gitannex"
is the command to run. But git-annex needs a git-annex-remote-rclone or similar,
so they are shipping a git-annex-remote-rclone-builtin symlink to rclone,
and when run under that name it behaves as if "rclone gitannex" were run.
So in this case, the need for "git-annex-remote-foo" is complicating an
upstream project that has gone out of its way to support git-annex. Not ideal.
From the pull request, @dmcardle wrote:
> My taste would be to implement a more generic mechanism rather than adding a special case for rclone gitannex.
> What if externaltype could be repeated, so that git annex initremote MyRemote type=external externaltype=rclone >
> externaltype=gitannex ... would cause git-annex to exec rclone with the additional gitannex arg?
But, that seems to present a security problem. Consider an attacker who runs
`git-annex initremote foo type=external autoenable=true externaltype=rm externaltype=/foo`
My conclusion is that git-annex can't provide a generic way to run a different
command for an external special remote. Any such commands need to be
whitelisted in some way. And if they're whitelisted, it seems better to not
require the user to enter additional parameters at all.
So one way would be to make "git-annex initremote foo type=external externaltype=rclone-builtin"
run "rclone gitannex".
Or, git-annex add an internal rclone special remote, that is just
a wrapper around the external special remote, that makes it use
"rclone gitannex". "git-annex initremote foo type=rclone" --[[Joey]]