aboutsummaryrefslogtreecommitdiff
path: root/doc/bugs/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_5_fa6d5d0afdc00824da0e04d9bf23d6f4._comment
blob: 2f7c8479efc0d6e45917f6c0399670eff90d3405 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[[!comment format=mdwn
 username="joey"
 subject="""comment 5"""
 date="2017-09-28T16:03:28Z"
 content="""
Files are not unlocked before modifying in direct mode, and may be
unlocked all the time in v6 mode. Also, in indirect mode it's of course
fine to overwrite the symlink with a new version of a file. So detecting 
if it's been unlocked doesn't seem to help with this.

It may be that there are different sorts of metadata, some of which should
be inherited by new versions of a file, and others not. If there was a way
to tell git-annex which metadata was which, it could do the right thing.
But it feels like stacking complications. Particularly since there might be
some tags that should be inherited and others not, and tags are values..

In the meantime, I've added the warning when it copies metadata. 
I also added `git annex metadata --remove-all`, which the warning
suggests running if you don't want the copied metadata.
"""]]