analysis

1 files changed, 21 insertions, 0 deletions

diff --git a/doc/bugs/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_1_cd7043b66977b2a668bbd52f4d8e31ff._comment b/doc/bugs/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_1_cd7043b66977b2a668bbd52f4d8e31ff._comment
new file mode 100644
index 000000000..b4eef0dab
--- /dev/null
+++ b/doc/bugs/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_1_cd7043b66977b2a668bbd52f4d8e31ff._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-09-26T18:17:58Z"
+ content="""
+This is caused by an intentional feature. When `git annex add` is run
+on a modified file, the old metadata for the file (as committed to HEAD)
+is copied over. This prevents metadata being lost when modifying a file.
+
+The same would happen if the file were deleted and then new content added
+with the same filename. It seems like different things should be done in
+these cases, but the same thing can end up staged in several different
+cases, so the cases can't be distinguished.
+
+Committing the rename or deletion before adding a file back with the same
+name allows distinguishing from a modification of the file, and so that
+avoids the problem.
+
+I agree this led to confusing behavior here, but I'll bet it's also
+prevented confusing loss of metadata for people when editing a file..
+"""]]