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-05-24 16:43:06 -04:00
parent 125a28c58e
commit 9a5981a153
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 29 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

29
doc/bugs/indeterminite_preferred_content_state_for_duplicated_file/comment_14_cb531e5fda28a3114420063106a2131b._comment Normal file
View file

@ -0,0 +1,29 @@
[[!comment format=mdwn
username="joey"
subject="""comment 14"""
date="2021-05-24T20:33:16Z"
content="""
@Ilya, it's different than git-annex unused because that looks at other
branches and tags. Preferred content only relates to the currently checked
out branch.
The only preferred contents expressions that this bug affects are include=
and exclude= ones. For an expression like copies=1, the key's content is
present or not, no matter how many files in the working tree might use that
key.
> * a given key is wanted in a repo if the preferred content expression is true for *any* file path which uses the key
Well not exactly, if foo and bar use the same content, and preferred
content is set to include=foo, and I run `git annex get --auto bar`, it
will not get the content despite bar's key also being used by foo, which is
preferred content. I only asked the command to act on bar. That is not
going to change. When the content is present, `git annex drop --auto bar`
will, once this is fixed, avoid dropping the content because it knows foo
also uses it.
I don't think this needs to change user's understanding of how preferred
content works. It's just git-annex being smart enough to prevent a situation
where repeated `git annex get --auto; git-annex drop --auto` would continually
do work, rather than reaching a stable point.
"""]]