comment
This commit is contained in:
parent
125a28c58e
commit
9a5981a153
1 changed files with 29 additions and 0 deletions
|
@ -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.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue