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

Warn when metadata is inherited from a previous version of a file

Browse source 
to avoid the user being surprised in cases where that behavior is not desired or expected

This commit was supported by the NSF-funded DataLad project.
This commit is contained in:
Joey Hess 2017-09-28 12:56:35 -04:00
parent 812d90022b
commit 4d0e522b72
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 47 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

20
doc/bugs/set_metadata_leaks_from_one___40__staged__41___key_to_another_during_rename_of_file/comment_5_fa6d5d0afdc00824da0e04d9bf23d6f4._comment Normal file
View file

@ -0,0 +1,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.
"""]]