document that multiple groupwanted are not combined
This commit is contained in:
parent
e615357bdd
commit
1694642969
3 changed files with 44 additions and 5 deletions
|
@ -0,0 +1,34 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2018-06-12T16:17:30Z"
|
||||
content="""
|
||||
groupwanted expressions are only used when there is only one that the
|
||||
repository could use. The repository can be in two groups and if only one
|
||||
of the groups has a groupwanted expression, it will be used, but if both
|
||||
do, neither expression will be used.
|
||||
|
||||
This limitation to exactly one expression also holds for standard
|
||||
preferred content expressions (which is documented).
|
||||
git-annex does not try to combine together two expressions with OR.
|
||||
Why not? Well, consider the standard preferred content expressions for the
|
||||
client and transfer groups. The one for transfer looks at whether client
|
||||
repositories have the content:
|
||||
`not (inallgroup=client and copies=client:2) ...`
|
||||
|
||||
If a repository is both a transfer repository and a client at the same
|
||||
time, that would make it want to have content as long as not all clients
|
||||
contain the content -- so once all other clients get the content, the
|
||||
repository would want to drop its copy. But then, it would see that
|
||||
not all client repositories now have the content (since it doesn't!) and
|
||||
want to get it. And potentially round and round..
|
||||
|
||||
git-annex actually detects and prevents this kind of drop/get cycle
|
||||
(probably), but the right behavior of combining those two groupwanted
|
||||
expressions is at best undefined. So it's better to have the user write
|
||||
down an expression with what they really want to happen than try to OR
|
||||
expressions.
|
||||
|
||||
I've updated the docs for groupwanted to note that it's only used when one
|
||||
of a repos's groups has it.
|
||||
"""]]
|
|
@ -21,6 +21,10 @@ make repositories in the group want to contain 3 copies of every file:
|
|||
git annex wanted $repo groupwanted
|
||||
done
|
||||
|
||||
Note that there must be exactly one groupwanted expression configured
|
||||
amoung all the groups that a repository is in; if there's more than one,
|
||||
none of them will be used.
|
||||
|
||||
# SEE ALSO
|
||||
|
||||
[[git-annex]](1)
|
||||
|
|
|
@ -172,12 +172,13 @@ elsewhere to allow removing it).
|
|||
* `groupwanted`
|
||||
|
||||
The "groupwanted" keyword can be used to refer to a preferred content
|
||||
expression that is associated with a group. This is like the "standard"
|
||||
keyword, but you can configure the preferred content expressions
|
||||
using `git annex groupwanted`.
|
||||
expression that is associated with a group, as long as there is exactly
|
||||
one such expression amoung the groups a repository is in. This is like
|
||||
the "standard" keyword, but you can configure the preferred content
|
||||
expressions using `git annex groupwanted`.
|
||||
|
||||
Note that when writing a groupwanted preferred content expression,
|
||||
you can use all of the keywords listed above, including "standard".
|
||||
When writing a groupwanted preferred content expression,
|
||||
you can use all the keywords documented here, including "standard".
|
||||
(But not "groupwanted".)
|
||||
|
||||
For example, to make a variant of the standard client preferred content
|
||||
|
|
Loading…
Reference in a new issue