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

doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway/comment_1_30a0a715fb9d8738e5ec53296375c1b3._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="chris@f4ea67aa5ae4709d79959f782fcebb5edae9a79b"
+ nickname="chris"
+ subject="similar problem"
+ date="2016-06-02T16:28:18Z"
+ content="""
+For me it's a version 6 repository, but I also get lots of queued transfers to my \"metadata only\" git-remote-gcrypt repo when I launch the webapp. Luckily they don't actually seem to turn up amongst the remote repo's objects (unless I'm missing something), but it causes the assistant to be busy being useless for a while.
+"""]]

doc/bugs/fsck__44___no_known_copies.mdwn

@@ -0,0 +1,33 @@
+### Please describe the problem.
+
+Sometimes I end up having files whose contents _do_ exist in this repo, but the location log says otherwise.
+
+For indirect repos, I can just run `annex fsck` on the directory, it says "(fixing location log)", and everything is fine.
+
+But when I try to do the same in a _direct_ repo, it refuses to admit that it just found a copy:
+
+[[!format text """
+┌ frost ~/Attic/Anime (annex)
+┘ annex fsck Foo/
+fsck Foo/[HorribleSubs] Foobar - 01 [720p].mkv (checksum...) 
+  ** No known copies exist of Foo/[HorribleSubs] Foobar - 01 [720p].mkv
+failed
+fsck Foo/[HorribleSubs] Foobar - 02 [720p].mkv (checksum...) 
+  ** No known copies exist of Foo/[HorribleSubs] Foobar - 02 [720p].mkv
+failed
+...and so on.
+"""]]
+
+(A copy _does_ exist; after all, `annex` just spent 30 seconds checksumming it.)
+
+I work around this bug by switching to indirect mode temporarily, which allows fsck to fix the log.
+
+### What steps will reproduce the problem?
+
+For the fsck bug, I think you just need a file that physically exists in the repo, but not marked as such in the location log.
+
+As for how such files happen in the first place, I've no idea myself. (For what it's worth, the log seems fine.)
+
+### What version of git-annex are you using? On what operating system?
+
+Arch's community/git-annex 6.20160511

doc/bugs/git_annex_adjust_--unlock_seems_to_cause_migration_of_a_file_to_another_backend.mdwn

@@ -0,0 +1,58 @@
+### Please describe the problem.
+
+Interestingly, on my first attempt I had two files which migrated from MD5 to MD5E backend, but may be I have done some steps differently which provoked also  also utils/test/test_data.tar.gz to get to the same destiny (actually later replicated on a fresh clone).
+I am also a bit confused why git diff reports change in the symlink if file is already a real file (I guess all the smudging magic)
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+(git)smaug:~exppsy/freesurfer-upstream2[master]git
+$> git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+nothing to commit, working directory clean
+
+$> git annex adjust --unlock
+adjust
+Checking out files: 100% (468/468), done.
+Switched to branch 'adjusted/master(unlocked)'
+ok
+git annex adjust --unlock  23.70s user 35.25s system 32% cpu 2:59.41 total
+changes on filesystem:
+ vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh | 2 +-
+
+$> git status
+On branch adjusted/master(unlocked)
+Changes not staged for commit:
+  (use "git add <file>..." to update what will be committed)
+  (use "git checkout -- <file>..." to discard changes in working directory)
+
+        modified:   vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh
+
+no changes added to commit (use "git add" and/or "git commit -a")
+changes on filesystem:
+ vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh | 2 +-
+
+$> git diff
+diff --git a/vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh b/vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh
+index 9ea90d3..7bc0177 100644
+--- a/vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh
++++ b/vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh
+@@ -1 +1 @@
+-/annex/objects/SHA256-s655672--85f9b50e8fb8a72a8783152c7ad098c0600222256a7244ccd595cbe67b9ea949
++/annex/objects/SHA256E-s655672--85f9b50e8fb8a72a8783152c7ad098c0600222256a7244ccd595cbe67b9ea949.mgh
+changes on filesystem:
+ vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh | 2 +-
+
+$> ls -ld vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh
+-rw------- 1 yoh yoh 655672 Jun  1 23:28 vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh
+
+$> git annex version
+git-annex version: 6.20160523+gitg33c00ab-1~ndall+1
+
+"""]]
+
+
+[[!meta author=yoh]]

doc/special_remotes/comment_36_48859c5ea8f63e37b7531ed0e07f4a54._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Dilyin"
+ subject="Special remote's annex cost"
+ date="2016-06-01T18:44:15Z"
+ content="""
+Looks like it's not possible to set the annex cost of the \"web\" and \"bittorrent\" special remotes annex cost.
+
+This doesn't seem to work:
+
+[remote \"web\"]
+  annex-cost = 500
+
+Perhaps, because these remotes don't actually exist.
+
+Setting annex cost for a webdav remote works but is incremented by 50 for some reason.
+
+"""]]

doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_6_1eceb980814f95b28caac9d4d9894f01._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Dilyin"
+ subject="Retroactively annex"
+ date="2016-06-01T18:36:40Z"
+ content="""
+Hmm, guyz? Are you serious with these scripts?
+
+1. git rm -r --cached large_files
+# files are indexed as both removed and untracked and are still in place
+2. commit the changes
+# files are seen as untracked
+3. git annex add large_files
+# files are replaced with symlinks and are in the index
+4. commit changes again
+
+Make sure that you don't have annex.largefiles settings that would prevent annexing the files.
+"""]]

doc/todo/checkpresentkey_without_explicit_remote.mdwn

@@ -2,4 +2,4 @@ While being asked to check if file is available from "[datalad-archives]" remote
 
 [[!meta author=yoh]]
 
-> [[done]]] --[[Joey]]
+> [[done]] --[[Joey]]

doc/todo/use_CoW_capability___40__e.g._cp_--reflink__41___while_adjust_--unlock.mdwn

@@ -0,0 +1,3 @@
+I might be wrong but given the observation that adjust --unlock took  26.04s user 33.95s system 31% cpu 3:12.36 total   to finish operation on an annex (on smaug, btrfs filesystem) with a relatively small (~400) number of relatively large files, I guess no reflink copying was done.
+
+[[!meta author="yoh"]]