From c4e7b2a4d469b685d2f018edabb2d622f3bd5515 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawnWwEEA3CurHkBjIYaJsJzFc4jtY2SCkrQ" Date: Tue, 29 Oct 2013 00:29:03 +0000 Subject: [PATCH 1/4] Added a comment --- .../comment_2_d19bc268c9467d24baa8d8f77a6e5e09._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/todo/whishlist:_git_annex_drop_--dry-run/comment_2_d19bc268c9467d24baa8d8f77a6e5e09._comment diff --git a/doc/todo/whishlist:_git_annex_drop_--dry-run/comment_2_d19bc268c9467d24baa8d8f77a6e5e09._comment b/doc/todo/whishlist:_git_annex_drop_--dry-run/comment_2_d19bc268c9467d24baa8d8f77a6e5e09._comment new file mode 100644 index 0000000000..3f11029851 --- /dev/null +++ b/doc/todo/whishlist:_git_annex_drop_--dry-run/comment_2_d19bc268c9467d24baa8d8f77a6e5e09._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawnWwEEA3CurHkBjIYaJsJzFc4jtY2SCkrQ" + nickname="Diego" + subject="comment 2" + date="2013-10-29T00:28:51Z" + content=""" +That makes sense, and thanks for adding this feature so quickly! +"""]] From bd07d034510f35810c8746c46dfc5dcee343e230 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkJafmCf-sg9_OM0pynFYM3AO4WCgJiaMI" Date: Tue, 29 Oct 2013 11:56:22 +0000 Subject: [PATCH 2/4] Added a comment: possible explanation --- ..._0246fff6c7c75f6be45bd257ec3872a5._comment | 75 +++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_3_0246fff6c7c75f6be45bd257ec3872a5._comment diff --git a/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_3_0246fff6c7c75f6be45bd257ec3872a5._comment b/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_3_0246fff6c7c75f6be45bd257ec3872a5._comment new file mode 100644 index 0000000000..0ffb2a0972 --- /dev/null +++ b/doc/forum/receiving_indirect_renames_on_direct_repo___63__/comment_3_0246fff6c7c75f6be45bd257ec3872a5._comment @@ -0,0 +1,75 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkJafmCf-sg9_OM0pynFYM3AO4WCgJiaMI" + nickname="Michele" + subject="possible explanation" + date="2013-10-29T11:56:21Z" + content=""" +now, i tried to understand what happens. Instead of issuing the *git annex sync*, I relied on *git pull origin, git merge origin/master*, (I red [[http://git-annex.branchable.com/forum/Help_Windows_walkthrough/]] and I assume that pull origin / merge origin/master would work similarly to the \"download\" part of sync, *except for losing all my direct content*) just to understand what was going on, with a clarifying result: + +while git annex sync fails on push, git pull origin fails on pull: + + M:\win>git pull origin + Updating 5408d6f..c566a69 + error: Your local changes to the following files would be overwritten by merge: + myfile + Please, commit your changes or stash them before you can merge. + Aborting + +note that the file has not been modified locally (just got it through git annex get). +issuing a git diff, reveals: + + M:\win>git diff myfile + diff --git a/myfile b/myfile + index beaf3e8..dc5b4ff 120000 + --- a/myfile + +++ b/myfile + @@ -1 +1 @@ + -.git/annex/objects/z5/v7/SHA256E-s8--6090923ed0931dcc6699f32fb66fa4ba32c10924088b12c66fb4ce35a91ba98c/SHA256E-s8\ No newline at end of file + +linux.1 + (END) + +ok, i follow suggestion, and I perform a git stash. that still wouldn't suffice for git annex sync: + + M:\win>git annex sync + commit + ok + pull origin + ok + push origin + To ssh://michele@home/home/michele/homebase + ! [rejected] master -> synced/master (non-fast-forward) + error: failed to push some refs to 'ssh://michele@home/home/michele/homebase' + hint: Updates were rejected because a pushed branch tip is behind its remote + hint: counterpart. Check out this branch and merge the remote changes + hint: (e.g. 'git pull') before pushing again. + hint: See the 'Note about fast-forwards' in 'git push --help' for details. + failed + git-annex: sync: 1 failed + +now, i can perform instead a *git pull origin*, since I am confident my content is stashed. + + M:\win>git pull origin + Updating 5408d6f..c566a69 + Fast-forward + myfile => myfile.renamed | 0 + 1 file changed, 0 insertions(+), 0 deletions(-) + rename myfile => myfile.renamed (100%) + +merge is not doing anything more: at this stage content has gone (file is a direct-mode symlink nad it cannot be fixed by fsck). +But i can recover it from stash (and I must do it unless I want to get the annex to think i still have content). + + git stash apply + +voilà: the content is there! and the repos seems in good order. +this only adds up that this is possibily a bug in the fact that git reports direct content as modified when indeed it hasn't been modified: but this affects git annex sync only when merging renaming files. +git annex sync now works perfectly . + +to sum it up, I have two questions: + +1) does using stash to circumvent the problem expose me to any risk ? +2) would the behaviour on receiving renames in the abovementioned situation worth to be signaled as a bug ? + + + + +"""]] From 46f6531caa4538d704b1b0469b563a0be13ee0cd Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmGxww5ON3nilm7moGQCWJPnMEdRwNvb7U" Date: Tue, 29 Oct 2013 20:21:03 +0000 Subject: [PATCH 3/4] --- ...40__notably_including_dead_ones__41__.mdwn | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 doc/bugs/git_annex_dead_does_not_work_as_expected_when_multiple_repos_exist_with_the_same_name___40__notably_including_dead_ones__41__.mdwn diff --git a/doc/bugs/git_annex_dead_does_not_work_as_expected_when_multiple_repos_exist_with_the_same_name___40__notably_including_dead_ones__41__.mdwn b/doc/bugs/git_annex_dead_does_not_work_as_expected_when_multiple_repos_exist_with_the_same_name___40__notably_including_dead_ones__41__.mdwn new file mode 100644 index 0000000000..8ec02de84e --- /dev/null +++ b/doc/bugs/git_annex_dead_does_not_work_as_expected_when_multiple_repos_exist_with_the_same_name___40__notably_including_dead_ones__41__.mdwn @@ -0,0 +1,44 @@ +### Please describe the problem. + +Creating two repos with the same name causes git annex dead to randomly choose one. This is reasonable except that it can choose to mark an already dead remote dead (as long as it shares the name), causing it to actually do nothing. + +I think preferring to mark live repos dead and printing a warning when multiple repos could have been chosen would be a good solution. + +### What steps will reproduce the problem? + +1. Create a new repo /somecopy + + git clone /central /somecopy + cd /somecopy + git annex init somecopy + git annex sync + cd / + +Now, git annex status shows somecopy as an existing repo. + +2. Destroy the new repo + + rm -rf /somecopy + cd /central + git annex dead somecopy + +git annex status correctly hides somecopy, and it is properly dead. + +3. create it again with the same name, but new UUID + + git clone /central /somecopy + cd /somecopy + git annex init somecopy + git annex sync + cd / + +4. Destroy the second repo + + rm -rf /somecopy + cd /central + +Now, git annex dead somecopy will randomly (based on the order of the UUIDs?) choose to mark dead the already dead old repo or the new repo, in both cases showing success to the user. + +### What version of git-annex are you using? On what operating system? + +git-annex 4.20131024 on linux. Also occurs on OSX. From c63bc1a40c6efa79a89ec372bc695b1942d0c355 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmGxww5ON3nilm7moGQCWJPnMEdRwNvb7U" Date: Tue, 29 Oct 2013 20:25:47 +0000 Subject: [PATCH 4/4] formatting --- ...40__notably_including_dead_ones__41__.mdwn | 48 +++++++++---------- 1 file changed, 23 insertions(+), 25 deletions(-) diff --git a/doc/bugs/git_annex_dead_does_not_work_as_expected_when_multiple_repos_exist_with_the_same_name___40__notably_including_dead_ones__41__.mdwn b/doc/bugs/git_annex_dead_does_not_work_as_expected_when_multiple_repos_exist_with_the_same_name___40__notably_including_dead_ones__41__.mdwn index 8ec02de84e..cbf79ffafc 100644 --- a/doc/bugs/git_annex_dead_does_not_work_as_expected_when_multiple_repos_exist_with_the_same_name___40__notably_including_dead_ones__41__.mdwn +++ b/doc/bugs/git_annex_dead_does_not_work_as_expected_when_multiple_repos_exist_with_the_same_name___40__notably_including_dead_ones__41__.mdwn @@ -6,36 +6,34 @@ I think preferring to mark live repos dead and printing a warning when multiple ### What steps will reproduce the problem? -1. Create a new repo /somecopy +[[!format sh """ +# Create a new repo /somecopy +git clone /central /somecopy +cd /somecopy +git annex init somecopy +git annex sync +cd / - git clone /central /somecopy - cd /somecopy - git annex init somecopy - git annex sync - cd / +# Now, git annex status shows somecopy as an existing repo. -Now, git annex status shows somecopy as an existing repo. +# Destroy the new repo +rm -rf /somecopy +cd /central +git annex dead somecopy -2. Destroy the new repo +# git annex status correctly hides somecopy, and it is properly dead. - rm -rf /somecopy - cd /central - git annex dead somecopy +# create it again with the same name, but new UUID +git clone /central /somecopy +cd /somecopy +git annex init somecopy +git annex sync +cd / -git annex status correctly hides somecopy, and it is properly dead. - -3. create it again with the same name, but new UUID - - git clone /central /somecopy - cd /somecopy - git annex init somecopy - git annex sync - cd / - -4. Destroy the second repo - - rm -rf /somecopy - cd /central +# Destroy the second repo +rm -rf /somecopy +cd /central +"""]] Now, git annex dead somecopy will randomly (based on the order of the UUIDs?) choose to mark dead the already dead old repo or the new repo, in both cases showing success to the user.