mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Added a comment

Browse source
This commit is contained in:
http://joeyh.name/ 2013-07-16 19:08:49 +00:00 • committed by admin
parent f6d36d34ed
commit e9d2a34364
1 changed files with 12 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

12
doc/bugs/git_annex_uninit_loses_content_when_interrupted/comment_2_0e99f6ef4f8b342ef0ebc64dbf8e2ce6._comment Normal file
View file

@ -0,0 +1,12 @@
[[!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
"""]]