This commit is contained in:
Joey Hess 2024-04-17 13:11:17 -04:00
parent c64a73c7ea
commit 5c542c0382
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38

View file

@ -1,11 +1,12 @@
rclone now supports being run as a git-annex special remote natively rclone now supports being run as a git-annex special remote natively
see <https://github.com/rclone/rclone/pull/7654>. "rclone gitannex" 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, 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, 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. 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 rclone won't be shipping that symlink, so users will have to create it
upstream project that has gone out of its way to support git-annex. Not ideal. themselves, which complicates using it. So could git-annex instead
support running "rclone gitannex" itself?
From the pull request, @dmcardle wrote: From the pull request, @dmcardle wrote:
@ -27,3 +28,19 @@ run "rclone gitannex".
Or, git-annex add an internal rclone special remote, that is just Or, git-annex add an internal rclone special remote, that is just
a wrapper around the external special remote, that makes it use a wrapper around the external special remote, that makes it use
"rclone gitannex". "git-annex initremote foo type=rclone" --[[Joey]] "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]]