summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorGravatar https://www.google.com/accounts/o8/id?id=AItOawlgyVag95OnpvSzQofjyX0WjW__MOMKsl0 <Sehr@web>2012-10-28 13:51:55 +0000
committerGravatar admin <admin@branchable.com>2012-10-28 13:51:55 +0000
commit35c724fbc580aae222301b7672d9aaa6f2dfea55 (patch)
treecb942108953766e1c8181f57a101e021176260a6 /doc
parent610c44eb68a072093060aa2f04210c1e4b917290 (diff)
Diffstat (limited to 'doc')
-rw-r--r--doc/bugs/__34__drop__34___deletes_all_files_with_identical_content.mdwn46
1 files changed, 46 insertions, 0 deletions
diff --git a/doc/bugs/__34__drop__34___deletes_all_files_with_identical_content.mdwn b/doc/bugs/__34__drop__34___deletes_all_files_with_identical_content.mdwn
new file mode 100644
index 000000000..2a23f80d8
--- /dev/null
+++ b/doc/bugs/__34__drop__34___deletes_all_files_with_identical_content.mdwn
@@ -0,0 +1,46 @@
+# What steps will reproduce the problem?
+
+ echo "TEST CONTENT" > fileA
+ cp fileA fileB
+ git annex add file{A,B}
+ git annex drop fileA --force
+ cat fileB
+
+# What is the expected output? What do you see instead?
+
+## expected:
+
+--> TEST CONTENT
+
+## observed:
+
+--> cat: fileB: No such file or directory
+
+
+# What version of git-annex are you using? On what operating system?
+
+git-annex version: 3.20120629
+
+# Please provide any additional information below.
+
+I really like git annex's feature, to store the same content only once. But as this happens transparently (i.e. the user does not need to no, nor is he told, that contents are identical (which is very comfortable, of course)), the "git annex drop" function is broken. For it effectively deleting (seemingly) random files, WITHOUT notifying the user.
+
+
+# Possible solution?
+
+One simple solution would be to use "git annex find" functionality to see who else uses the file and NOT deleting it.
+
+But this still leaves a problem:
+
+Consider the following variation of the above example and assume, that "drop" does not delete content that is still used (i.e. implementing the above solution).
+
+ echo "TEST CONTENT" > fileA
+ cp fileA fileB
+ git annex add file{A,B}
+ git rm fileB
+ git annex drop fileA --force
+ git checkout --force
+ cat fileB
+--> cat: fileB: No such file or directory
+
+Here again, the problem is, that the user would probably (correct me if I am wrong) expect that the fileB still exists, because removing a file and checking it out again is expected to not mess with the annex contents (?). He does not know, that the "annex frop fileA" actually drop fileB's contents, because there was no additional file linking to it. It effectively performed a "git annex dropunused".