Added a comment
authorwolf480@8ad1ccdd08efc303a88f7e88c4e629be6637a44e <wolf480@web>
Thu, 30 Mar 2023 17:33:10 +0000 (17:33 +0000)
committeradmin <admin@branchable.com>
Thu, 30 Mar 2023 17:33:10 +0000 (17:33 +0000)
doc/bugs/external_remote_export_sent_to_wrong_process/comment_4_db89603335995755d145141705ac4584._comment [new file with mode: 0644]

diff --git a/doc/bugs/external_remote_export_sent_to_wrong_process/comment_4_db89603335995755d145141705ac4584._comment b/doc/bugs/external_remote_export_sent_to_wrong_process/comment_4_db89603335995755d145141705ac4584._comment
new file mode 100644 (file)
index 0000000..fa9eff7
--- /dev/null
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="wolf480@8ad1ccdd08efc303a88f7e88c4e629be6637a44e"
+ nickname="wolf480"
+ avatar="http://cdn.libravatar.org/avatar/816b19ee786208f3216fe146d7733086"
+ subject="comment 4"
+ date="2023-03-30T17:33:10Z"
+ content="""
+Hmm but a remote only learns that it's being used with exporttree=yes *after* it has sent a `VERSION`?
+
+I'm afraid I can't bump the version in case of git-annex-remote-rclone, it's already widely used for non-exporttree scenarios and requiring a git-annex that supports `VERSION 2` for these existing usecases (which aren't affected by this bug) would be a regression...
+
+I'll ask git-annex-remote-rclone maintainers, but it seems to me that defensive coding around the `EXPORT` command is gonna be a better solution in this remote's case.
+"""]]