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

doc/bugs/--shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_3_aae8dd8b3b0ce4647ec2d30e1d682339._comment

@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2017-10-10T17:40:08Z"
+ content="""
+Found a following comment in the code
+[[!format haskell \"\"\"
+{- Normally, blocks writing to an annexed file, and modifies file
+ - permissions to allow reading it.
+ -
+ - When core.sharedRepository is set, the write bits are not removed from
+ - the file, but instead the appropriate group write bits are set. This is
+ - necessary to let other users in the group lock the file. But, in a
+ - shared repository, the current user may not be able to change a file
+ - owned by another user, so failure to set this mode is ignored.
+ -}
+\"\"\"]]
+So may be it is a \"Feature\" although killing the whole premise of data safety while using git-annex.
+
+In my case, shared permissions are primarily to make files/repositories readable by others, so may be I should have not used 'shared' mode anyways, since reading does not need the shared setting
+"""]]

doc/bugs/--shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_4_c72e6646e39cc487ea52cd17925a548f._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 4"
+ date="2017-10-10T17:56:47Z"
+ content="""
+our comments crossed in the hyperspace... ;)  yeah -- I would have expected a separate lock file to be used for such cases.  Now data loss is really a possibility (almost made it happen since opened the file and wrote it without unlocking, good that I caught it and was able to modify back exactly the way it was).  Interactions among multiple versions of annex on the same repo is imho a lesser possibility (would require two different versions of annex being available)
+"""]]

doc/forum/non_fast_forward_error_with_git_annex_sync.mdwn

@@ -0,0 +1,34 @@
+I'm trying to sync from a direct repo to another direct repo but getting a non-fast-forward rejection:
+
+    push v-crateris 
+    Counting objects: 509, done.
+    Delta compression using up to 4 threads.
+    Compressing objects: 100% (455/455), done.
+    Writing objects: 100% (509/509), 33.21 KiB | 4.74 MiB/s, done.
+    Total 509 (delta 350), reused 0 (delta 0)
+    remote: Resolving deltas: 100% (350/350), completed with 174 local objects.
+    To v-crateris:/annex/Music
+       c60621302..803920707  git-annex -> synced/git-annex
+     ! [rejected]            annex/direct/master -> synced/master (non-fast-forward)
+    error: failed to push some refs to 'v-crateris:/annex/Music'
+    hint: Updates were rejected because a pushed branch tip is behind its remote
+    hint: counterpart. Check out this branch and integrate the remote changes
+    hint: (e.g. 'git pull ...') before pushing again.
+    hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+    To v-crateris:/annex/Music
+     ! [rejected]            master -> master (non-fast-forward)
+    error: failed to push some refs to 'v-crateris:/annex/Music'
+    hint: Updates were rejected because a pushed branch tip is behind its remote
+    hint: counterpart. Check out this branch and integrate the remote changes
+    hint: (e.g. 'git pull ...') before pushing again.
+    hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+
+      Pushing to v-crateris failed.
+
+      (non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config)
+    failed
+
+I tried setting `receive.denyNonFastforwards` to `false` as the message said, but it made no difference.
+Both repos have `annex/direct/master` checked out.
+
+What should I do to resolve this?

doc/forum/non_fast_forward_error_with_git_annex_sync/comment_1_48d66e5314de5b6a26f78622a4e93ba6._comment

@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="matyasbot@fd008517d046c382e18306c0b3db48eb58d45dee"
+ nickname="matyasbot"
+ avatar="http://cdn.libravatar.org/avatar/c1b6b47dcdf2962858e6aad44a3cec66"
+ subject="pull didn't do anything either"
+ date="2017-10-11T14:23:29Z"
+ content="""
+Also, despite the pull claiming to have succeded, there was a new directory on the remote that did not get transferred to the local repo during the sync.
+"""]]