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

doc/forum/Git_repos_in_git_annex__63__/comment_3_88e37911a0280d817559b2d51ddb1d4e._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="memeplex"
+ avatar="http://cdn.libravatar.org/avatar/84a611000e819ef825421de06c9bca90"
+ subject="comment 3"
+ date="2017-04-14T22:35:49Z"
+ content="""
+Another use case is when you use annex for backup. For example I keep most of my files (dotfiles, scripts, music, books, etc) in a \"home\" git annex repo. Part of them is stored in google drive, part in a pendrive, part in my home computer, part in my work computer. Every once in a while I sync everything into my home computer and into an additional external hard drive remote that I keep as a backup. Sadly, my archived git projects can't be managed like that. Nevertheless, it's not a big deal since they are already in the cloud (gitlab or github) and in my local filesystem. Besides, since they are archived, I can just create tarballs and add them to the annex (and in case annex allowed to store .git directories, I'd not be really comfortable with the huge amount of symlinks that would produce).
+
+That said, it's kind of a bathos that the illusion of a distributed, decentralized, redundant, versioned, annotated, etc. filesystem over git is broken by git itself.   
+"""]]

doc/forum/Lots_of_4k_symlinks.mdwn

@@ -0,0 +1,24 @@
+Hi, 
+
+this is a minor issue and probably there is no better solution, but nevertheless I would like to point out it and maybe discuss a little about the issue.
+
+Given that the symlinks generated by annex are pretty large in size (they point to a file named by a large hash number), ext4 is using an entire block (4K) of storage instead of [embedding the symlink into the inode][inode] itself. For the "archivist use case" of annex, this might lead to tens or hundreds of MBs of disk occupied by symlinks which actually don't add up to more than a few MBs.
+
+Here is a real world example:
+
+```
+(ins)carlos@carlos home$ du -hs music/
+56M	music/
+(ins)carlos@carlos home$ du -bhs music/
+3.3M	music/
+(ins)carlos@carlos home$ ln -s /tmp/x x
+(ins)carlos@carlos home$ du x
+0	x
+(ins)carlos@carlos home$ ln -s /tmp/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xx
+(ins)carlos@carlos home$ du xx
+4	xx
+```
+
+Cheers, Carlos
+
+[inode]: https://kernelnewbies.org/Linux_3.8#head-372b38979138cf2006bd0114ae97f889f67ef46a

doc/forum/Synchronize_large_files___40__VM_images__41__/comment_2_bbd98d0b5d77dc7efc55ef8c2a18d612._comment

@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/hVbIabkhqO11.DpKUWBoztFSLD5q#8cbe8"
+ nickname="Murat"
+ avatar="http://cdn.libravatar.org/avatar/52d95e40aca820c1993077ef9aa676c75700a072511c143f6db6b78be6b1b212"
+ subject="Why is it takins too long?"
+ date="2017-04-18T16:26:06Z"
+ content="""
+Hi,
+due to my requirement I need to revert vm image every time before running it via \"git reset --hard\" which is really fast on the other hand \"git annex unlock\" takes really long, I run git-annex on Centos 6 and git-annex version git-annex-3.20120522-2.1.el6.x86_64, if I update git-annex version can it help to fasten \"unlock\"?
+
+thanks a lot
+
+"""]]

doc/forum/deploy.mdwn

@@ -0,0 +1,5 @@
+Greetings,
+
+I use the push-to-deploy pattern (as described in 4.1 http://gitolite.com/deploy.html). However, my git repo has large binary files that I'd like to annex. Is there an example of using git annex with a bare remote repository with the appropriate post-receive hook to accomplish the deploy?
+
+Thanks

doc/tips/Faster_bash_autocompletion_with_big_annex_repos.mdwn

@@ -0,0 +1,50 @@
+I'm currently using git annex to manage my entire file collection
+(including tons of music and books) and I noticed how slow
+autocompletion has become for files in the index (say for git add).
+The main offender is a while-read-case-echo bash loop in
+`__git_index_files` that can be readily substituted with a much faster
+sed invocation. Here is my benchmark:
+
+```
+__git_index_files ()
+{
+    local dir="$(__gitdir)" root="${2-.}" file;
+    if [ -d "$dir" ]; then
+        __git_ls_files_helper "$root" "$1" | while read -r file; do
+            case "$file" in
+                ?*/*)
+                    echo "${file%%/*}"
+                ;;
+                *)
+                    echo "$file"
+                ;;
+            esac;
+        done | sort | uniq;
+    fi
+}
+
+time __git_index_files > /dev/null
+
+real    0m0.830s
+user    0m0.597s
+sys    0m0.310s
+
+__git_index_files ()
+{
+    local dir="$(__gitdir)" root="${2-.}" file;
+    if [ -d "$dir" ]; then
+        __git_ls_files_helper "$root" "$1" | \
+            sed -r 's@/.*@@' | uniq | sort | uniq
+    fi
+}
+
+
+time __git_index_files > /dev/null
+
+real    0m0.075s
+user    0m0.083s
+sys    0m0.010s
+
+```
+
+10 times faster! So you might redefine `__git_index_files` as above in your .bashrc after sourcing the git autocomplete script.