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 to use it needs a git-annex-remote-rclone-builtin symlink to rclone, and when run under that name it behaves as if "rclone gitannex" were run.
rclone won't be shipping that symlink, so users will have to create it themselves, which complicates using it. So could git-annex instead support running "rclone gitannex" itself?
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
Considering those two approaches again, the first would let the new rclone be used with old git-annex with the user making the git-annex-remote-rclone-builtin symlink. Then later, that same special remote could be used with the new git-annex on a system where that symlink was not set up.
The second approach would make a special remote that can't be used with old git-annex. But if the user wanted to use the new rclone with old git-annex, they can still make the symlink. To later migrate away from the symlink, they would need to initremote another special remote using --sameas.
I feel that the simplicity of the type=rclone config will pay off in the long term, vs short term complication for probably a small subset of users who somehow can upgrade rclone but can't upgrade git-annex. --Joey
git-annexis pretty much following git's owngit-remote-paradigm here, I think it is ok to requiregit-annex-remote-to even simply be able to check what are the availablegit-annexremotes etc. Providing a shim to pass through to some tool specific interface is IMHO trivial enough. And as you outline, such approach also helps to avoid a security concern.