From f7e2d0c045409697031e32a1c656c5f8d2f6922e Mon Sep 17 00:00:00 2001 From: yarikoptic Date: Tue, 10 Oct 2017 17:40:08 +0000 Subject: Added a comment --- ...ent_3_aae8dd8b3b0ce4647ec2d30e1d682339._comment | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 doc/bugs/--shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_3_aae8dd8b3b0ce4647ec2d30e1d682339._comment 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 +"""]] -- cgit v1.2.3 From c4d1b26d878afc24993f8047309bf3a4bbbe7cec Mon Sep 17 00:00:00 2001 From: yarikoptic Date: Tue, 10 Oct 2017 17:56:47 +0000 Subject: Added a comment --- .../comment_4_c72e6646e39cc487ea52cd17925a548f._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/bugs/--shared_setting_of_git_causes_annex__39__ed_files_to_be_writeable__33__/comment_4_c72e6646e39cc487ea52cd17925a548f._comment 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) +"""]] -- cgit v1.2.3 From 80dcb130df352e87e761cd727e53594961c30cc7 Mon Sep 17 00:00:00 2001 From: "matyasbot@fd008517d046c382e18306c0b3db48eb58d45dee" Date: Wed, 11 Oct 2017 14:16:57 +0000 Subject: --- ...non_fast_forward_error_with_git_annex_sync.mdwn | 34 ++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 doc/forum/non_fast_forward_error_with_git_annex_sync.mdwn 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? -- cgit v1.2.3 From cc333d6c8ec94208c7cebfcaccaf374aff35df1d Mon Sep 17 00:00:00 2001 From: "matyasbot@fd008517d046c382e18306c0b3db48eb58d45dee" Date: Wed, 11 Oct 2017 14:23:29 +0000 Subject: Added a comment: pull didn't do anything either --- .../comment_1_48d66e5314de5b6a26f78622a4e93ba6._comment | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/forum/non_fast_forward_error_with_git_annex_sync/comment_1_48d66e5314de5b6a26f78622a4e93ba6._comment 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. +"""]] -- cgit v1.2.3