diff options
Diffstat (limited to 'doc/bugs/git_annex_uninit_loses_content_when_interrupted')
2 files changed, 0 insertions, 20 deletions
diff --git a/doc/bugs/git_annex_uninit_loses_content_when_interrupted/comment_1_fd9d2abbc90fb4f470b2212bc1f4a2dd._comment b/doc/bugs/git_annex_uninit_loses_content_when_interrupted/comment_1_fd9d2abbc90fb4f470b2212bc1f4a2dd._comment deleted file mode 100644 index f9865ca69..000000000 --- a/doc/bugs/git_annex_uninit_loses_content_when_interrupted/comment_1_fd9d2abbc90fb4f470b2212bc1f4a2dd._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.90" - subject="comment 1" - date="2013-07-16T18:29:37Z" - content=""" -All you have to do to get file1 back is check its symlink back out of git's history. `git checkout file1` should suffice to recover. \"Loses content\" is way overstating the severity of this bug. -"""]] diff --git a/doc/bugs/git_annex_uninit_loses_content_when_interrupted/comment_2_0e99f6ef4f8b342ef0ebc64dbf8e2ce6._comment b/doc/bugs/git_annex_uninit_loses_content_when_interrupted/comment_2_0e99f6ef4f8b342ef0ebc64dbf8e2ce6._comment deleted file mode 100644 index 2b6fc4186..000000000 --- a/doc/bugs/git_annex_uninit_loses_content_when_interrupted/comment_2_0e99f6ef4f8b342ef0ebc64dbf8e2ce6._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.90" - subject="comment 2" - date="2013-07-16T19:08:49Z" - content=""" -However, if you then run `git annex uninit` a second time, it goes ahead and deletes the content! That is a bug. - -I looked into trying to make uninit always replace the symlink atomically with the file content. It can't be done when using --fast, since it's not possible to atomically replace a symlink with a hard link (AFAIK). It should be possible to do it in the normal mode, but it would require manually constructing a commit, since git does not provide a way to delete a file from the index and commit that staged change without also committing any other changes that are staged -- and uninit should preseve any changes to non-annexed files that the user has staged. So, I don't think atomic operation is the right answer. - -Instead, I have made uninit refuse to delete .git/annex/objects unless it's empty, and if objects are still left in there, for whatever reason, it'll fail at the end with a nice message explaining some options. I think this is the right fix because it also avoids uninit removing historical versions of files that were stored in git-annex.g -"""]] |