[[!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.
"""]]
