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

comment

Browse source
This commit is contained in:
Joey Hess 2021-04-16 13:49:05 -04:00
parent 71e41eb03c
commit 7496c86c7c
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 27 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

27
doc/todo/option_to___96__drop_path__96___to_not_drop___34__all_copies__34__/comment_1_8f40b2663c9f48ddb07969af1b6632a8._comment Normal file
View file

@ -0,0 +1,27 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2021-04-16T17:33:39Z"
content="""
Problem is git-annex does not keep track of the information it would need
in order to do this. Same problem as in
[[bugs/indeterminite_preferred_content_state_for_duplicated_file]].
Unlike that bug, I think it's actually rather ambiguous whether the user
wants the file to be dropped in this case. Obviously you want it not to,
the way your file tree is arranged, but other could
rely on the current behavior.
Here's one way: Imagine a repo storing music. It has directories for
albums, and also directories containing playlists, which are copies of
files from albums. If I was in a mood for Brazilian music, but have gotten
over it for now, I might want to drop Brazilian_playlist (which got very
long in my travels there) to free up some space. If it refused to drop
files because the same files were also in the corresponding album
directories, I would wonder why git-annex had gotten broken.
But the --not-used-elsewhere switch seems reasonable, if the needed info
was available. I suppose git-annex could scan the index for changes and
update state when this switch was used. Could be slow to update
that state though.
"""]]