Merge branch 'master' into adjustedbranch

doc/bugs/Android__58___use___47__data__47____8230___for_git-annex.home__63__/comment_2_041fe2a545b48acd2c9d15eb2ac2b34f._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899"
+ nickname="divergentdave"
+ subject="comment 2"
+ date="2016-03-21T04:13:15Z"
+ content="""
+Each app has one subfolder inside /data that is private to that app (and user) alone. Generally, you can't read or enumerate /data itself. There is a function in the Java API to get the current app's internal storage folder, see https://developer.android.com/reference/android/content/Context.html#getFilesDir%28%29.
+"""]]

doc/bugs/Android_chroot_stuck_in_Cabal_hell.mdwn

@@ -0,0 +1,20 @@
+### Please describe the problem.
+I'm trying to get an Android development environment set up, but I am running into conflicting library versions inside of the chroot. The package installation script now finishes, but I run into a link-time error during `cabal configure` because it is pulling in two different versions of the unix package for some reason. Please let me know if there is any information I can get from my build environment that would help diagnosing the issue.
+
+### What steps will reproduce the problem?
+Run `buildchroot`, `install-haskell-packages`, `make android`
+
+### What version of git-annex are you using? On what operating system?
+Attempting to build from source, cross-compiling for Android on Debian Jessie.
+
+### Please provide any additional information below.
+
+[[!format sh """
+Linking ./dist/setup/setup ...
+/usr/lib/ghc/unix-2.6.0.1/libHSunix-2.6.0.1.a(execvpe.o): In function `pPrPr_disableITimers':
+(.text+0x300): multiple definition of `pPrPr_disableITimers'
+/home/builder/.cabal/lib/i386-linux-ghc-7.6.3/unix-2.7.1.0/libHSunix-2.7.1.0.a(ghcrts.o):ghcrts.c:(.text+0x0): first defined here
+collect2: error: ld returned 1 exit status
+Makefile:225: recipe for target 'android' failed
+make: *** [android] Error 1
+"""]]

doc/bugs/Git_copy_fails_with_absolute_path_on_mavericks.mdwn

@@ -0,0 +1,12 @@
+### Please describe the problem.
+
+git-annex version: 6.20160126
+
+Problem happens on Mavericks, not on Yosemite with same version.
+
+Can do a relative or absolute path on a git annex add.
+
+But on the git annex copy to an S3 remote, if I use an absolute path for the file descriptor (e.g. /Users/name/git_directory/test.txt) it will not report an error, but will also not print the "copied..." string. A subsequent call with a relative path (e.g. test.txt) will work, show the copied message and indeed show up on S3.
+
+
+Good news: It's working great on Yosemite!

doc/bugs/Git_copy_fails_with_absolute_path_on_mavericks/comment_1_2f0c74aba502533b85b922ea81ded70d._comment

@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-03-14T17:34:21Z"
+ content="""
+Using absolute paths to files is an unusual thing to do with git in my
+experience. But, git does seem to support it, at least some of the time.
+
+I think that git-annex's support for it comes down to what `git ls-files`
+does. For example:
+
+	joey@darkstar:~/tmp/me> git ls-files ~/tmp/me/foo
+	foo
+
+Since git-annex uses git ls-files, it sees a relative file and so
+all or most all git-annex commands can work with the absolute file input.
+
+Does git ls-files convert the absolute path to a relative path
+when you run it on the Mavericks system?
+
+What version of git is installed on the Mavericks system? Is
+git-annex installed from the git-annex app, or from homebrew, or how?
+"""]]

doc/bugs/MacOSX__58___archive_folders_not_working_as_expected/comment_3_4026607087a9da2759f841e59aadfcdc._comment

@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="nanotech"
+ subject="comment 3"
+ date="2016-03-17T08:39:36Z"
+ content="""
+I think this is the same bug as [Moved files are not picked up by the assistant on OS X](https://git-annex.branchable.com/bugs/Moved_files_are_not_picked_up_by_the_assistant_on_OS_X/). To reproduce, run the first transcript there but drop the file before moving it.
+
+FSEvents fails to produce add events for dangling symlinks (<https://github.com/facebook/watchman/issues/172>), although it does produce removal events. Recompiling and using Kqueue with git-annex instead seems to detect dangling symlinks and add them correctly.
+"""]]