From 4c1461932f725c8f7a4f2bc8622d04a38eb3ed5c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 15 Dec 2020 13:17:31 -0400 Subject: [PATCH] comment --- ..._a9fa5282774cc32ece9196b864435957._comment | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 doc/forum/What_is_going_on_here__63__/comment_4_a9fa5282774cc32ece9196b864435957._comment diff --git a/doc/forum/What_is_going_on_here__63__/comment_4_a9fa5282774cc32ece9196b864435957._comment b/doc/forum/What_is_going_on_here__63__/comment_4_a9fa5282774cc32ece9196b864435957._comment new file mode 100644 index 0000000000..0e9cc37113 --- /dev/null +++ b/doc/forum/What_is_going_on_here__63__/comment_4_a9fa5282774cc32ece9196b864435957._comment @@ -0,0 +1,28 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2020-12-15T17:08:21Z" + content=""" +git-annex initremote creates a *new* special remote. +(Back in version 4.20130501, initremote was also used +to enable an existing special remote so maybe you're remembering that, but +that was well before v5 anyway.) + +So, when you clone your gitlab repo, which you have not pushed the +git-annex branch to, and then initremote shared-storage, you are making a +brand new remote, not enabling the one you created earlier. +(If you had pushed the git-annex branch, the second initremote would +have complained that there was already a special remote by that name.) + +It's not possible that this brand new remote contains the content of +test.bin, at least as far as git-annex knows. Because it's brand new, and +so, presumably empty. + +I'm not sure what specific thing in the older version of git-annex +might have made that appear to work. But it certianly seems that +what you're doing does not make any sense, and I would not have expected +it to work with any version of git-annex. + +Nothing to do with v5 or v8 repository mode has anything to do with +this, certianly. +"""]]