summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2017-10-11 11:13:43 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2017-10-11 11:13:43 -0400
commita9cfdf992c1b08ec5bb76bfec8a1c3a4eaf09062 (patch)
tree24cda17be798da20373b5bf319bb20ce3ab9d622 /doc
parentc4d9c62d9d112feac32fc8b6d80adc694f1dd962 (diff)
parentcc333d6c8ec94208c7cebfcaccaf374aff35df1d (diff)
Merge branch 'master' of ssh://git-annex.branchable.com
Diffstat (limited to 'doc')
-rw-r--r--doc/bugs/--shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_3_aae8dd8b3b0ce4647ec2d30e1d682339._comment22
-rw-r--r--doc/bugs/--shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_4_c72e6646e39cc487ea52cd17925a548f._comment8
-rw-r--r--doc/forum/non_fast_forward_error_with_git_annex_sync.mdwn34
-rw-r--r--doc/forum/non_fast_forward_error_with_git_annex_sync/comment_1_48d66e5314de5b6a26f78622a4e93ba6._comment9
4 files changed, 73 insertions, 0 deletions
diff --git a/doc/bugs/--shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_3_aae8dd8b3b0ce4647ec2d30e1d682339._comment b/doc/bugs/--shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_3_aae8dd8b3b0ce4647ec2d30e1d682339._comment
new file mode 100644
index 000000000..9450cbc49
--- /dev/null
+++ b/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
+"""]]
diff --git a/doc/bugs/--shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_4_c72e6646e39cc487ea52cd17925a548f._comment b/doc/bugs/--shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_4_c72e6646e39cc487ea52cd17925a548f._comment
new file mode 100644
index 000000000..8e7b2ec6a
--- /dev/null
+++ b/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)
+"""]]
diff --git a/doc/forum/non_fast_forward_error_with_git_annex_sync.mdwn b/doc/forum/non_fast_forward_error_with_git_annex_sync.mdwn
new file mode 100644
index 000000000..19dad625b
--- /dev/null
+++ b/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?
diff --git a/doc/forum/non_fast_forward_error_with_git_annex_sync/comment_1_48d66e5314de5b6a26f78622a4e93ba6._comment b/doc/forum/non_fast_forward_error_with_git_annex_sync/comment_1_48d66e5314de5b6a26f78622a4e93ba6._comment
new file mode 100644
index 000000000..acde90fd2
--- /dev/null
+++ b/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.
+"""]]