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..cbf79ffafc --- /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,42 @@ +### 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? + +[[!format sh """ +# 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. + +# Destroy the new repo +rm -rf /somecopy +cd /central +git annex dead somecopy + +# git annex status correctly hides somecopy, and it is properly dead. + +# create it again with the same name, but new UUID +git clone /central /somecopy +cd /somecopy +git annex init somecopy +git annex sync +cd / + +# 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. 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 ? + + + + +"""]] 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! +"""]]