Hi joey,

While writing a more complex preferred content expression today I noticed that a `onlyingroup=GROUPNAME` condition would be handy.

Consider a sneakernet where clumps of nodes can communicate quickly with each other but the inter-clump communication is not so great. This is the case for my setup where a raspberry pi in the field has a USB stick attached (so two repos in `field` group), but their uplink is slow mobile data. Then I have an `offsite-backup` group for other disks/servers that I have access to.

When I sync content from within an `offsite-backup` repo, I don't want it to copy data via the slow mobile data - this I do via sneakernet by swapping the USB drive in the field from time to time. Not setting up the `field` repos here is possible but prevents syncing of metadata, which is not ideal.

If I could do `git annex groupwanted offsite-backup 'anything and not onlyingroup=field'`, the preferred content expression would be quite consise and short. `onlyingroup` would match if no other group has the file in question, only the given group. This would extend the functionality already provided by `inallgroup`.

Without `onlyingroup`, one has to basically hard-code the amount of repos in the group with a rather complex expression ( 2 in this case, the Pi and the USB drive):

```
(anything and not copies=field:1 or copies=untrusted+:2) or (anything and not copies=field:2 or copies=untrusted+:3)
```

One also has to specifically catch each combination case where files between the `field` group are (only on the Pi? Only on the USB drive? on both?). The `copies=untrusted+:2` is then needed to allow copying other files that are around (e.g. because they were indeed copied over mobile data) but still in the `field` group.

Maybe you see an easier way, but this is what I came up with. I think an `onlyingroup` expression would be very helpful.

Cheers,
Yann

> [[done]] --[[Joey]]
