aboutsummaryrefslogtreecommitdiff
path: root/doc/bugs/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_1_cd7043b66977b2a668bbd52f4d8e31ff._comment
blob: b4eef0dab877a6b0f4076b7388d58dec21351da9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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..
"""]]