Merge branch 'master' of ssh://git-annex.branchable.com

3 files changed, 79 insertions, 0 deletions

diff --git a/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_16_4ff2a87765b1584e55655b2a5451dd50._comment b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_16_4ff2a87765b1584e55655b2a5451dd50._comment
new file mode 100644
index 000000000..4d1ae78c1
--- /dev/null
+++ b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_16_4ff2a87765b1584e55655b2a5451dd50._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="threadshuffle"
+ subject="comment 16"
+ date="2015-08-04T21:46:17Z"
+ content="""
+Installed build 4839 and everything seems to work. One quick question though, doing sync on an origin and clone repos, shouldn't it make the git annex list look the same on both? I'm getting on the remote
+<pre>
+me@mint64vm ~/ga $ git annex list
+here
+|web
+||
+X_ me
+X_ me_local
+X_ me_origin
+</pre>
+And on the clone (after some copying, moving, dropping and sync)
+<pre>
+C:\Users\me\q\ga>git annex list
+here
+|origin
+||web
+|||bittorrent
+||||
+_X__ me
+_X__ me_local
+_X__ me_origin
+</pre>
+And, of course, thanks for the fix.
+"""]]
diff --git a/doc/forum/can__39__t_sync_content.mdwn b/doc/forum/can__39__t_sync_content.mdwn
new file mode 100644
index 000000000..9e7a4cc49
--- /dev/null
+++ b/doc/forum/can__39__t_sync_content.mdwn
@@ -0,0 +1,35 @@
+Hi,
+
+I'm completely new to git-annex, I'm trying to follow this guide:
+
+https://git-annex.branchable.com/tips/centralized_git_repository_tutorial/on_GitLab/
+
+All steps succeeded except the `git annex sync --content` which results in the following message:
+
+'Remote origin not usable by git-annex; setting annex-ignore'
+
+Here is an example of the output I receive:
+
+    $ git status
+    On branch master
+    Your branch is up-to-date with 'origin/master'.
+    nothing to commit, working directory clean
+    $
+    $ git push origin master git-annex
+    Everything up-to-date
+    $
+    $ git annex sync --content
+    
+      Remote origin not usable by git-annex; setting annex-ignore
+    commit  ok
+    pull origin
+    ok
+    pull origin
+    ok
+    $
+    $ git config remote.origin.url
+    https://user:pass@gitlab.com/user/repname.git
+
+Is it required to use the ssh protocol in order to get annex working?
+
+I'm using https since I'm behind a firewall, and the ssh protocol always time out. Is there anything I can do?
diff --git a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_4_2669ce8914d75eda225607d4d0b45ab0._comment b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_4_2669ce8914d75eda225607d4d0b45ab0._comment
new file mode 100644
index 000000000..e6c16db6d
--- /dev/null
+++ b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_4_2669ce8914d75eda225607d4d0b45ab0._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="my bad"
+ date="2015-08-05T02:33:46Z"
+ content="""
+indeed my use of ts timestamp was somewhat incorrect ;), I have used ts \"%b %d %H:%M:%S.%s\"
+
+\" This is quite likely simply the overhead of git-annex needing to query git to work out what remote each file is located on\" -- unlikely since CPU utilization is close to none.
+
+\"coupled with the overhead of needing to start a new git-annex-shell and rsync processes\" -- that is the likely major part of the overhead here 
+
+-J is indeed of notable help BUT overall disproportionate to mitigate the overhead at large.  I seem can successfully raise it to -J 4. With -J 6 I already start getting \"E: channel 22: open failed: administratively prohibited: open failed\" from time to time (not sure if it is benign or results in that particular transfer not succeeding). Not quite sure on the exact reason for it, i.e. why server side refuses to open a new channel -- I guess because of the same issue of too quickly following requests for new connections (i.e. \"the overhead\").
+  
+Why transfer requests could not be queued up and batched for execution within the same ssh invocation?  Keys are unique, so could be received within the same tmp/ in a batch transfer and then sorted into their corresponding hash subdirs.   Bundled with -J to possibly even split among multiple source remotes from which different content could be available from it could lead to greatly improved transfer rates.  Or would it be a major undertaking?
+"""]]