e1fc9e204e
This ended up having an interface like sync, rather than like get/copy/drop. That let it be implemented in terms of sync, which took a lot less code. Also, it lets it handle many of the edge cases that sync does, such as getting files that are not visible in a --hide-missing branch, and sending files to exporttree remotes. As well as being easier to implement, `git-annex satisfy myremote` makes sense as it satisfies the preferred content settings of the remote. `git-annex satisfy somefile` does not form a sentence that makes sense. So while -C can be a little bit annoying, it still makes sense to have this syntax. Note that, while I initially thought this would also satisfy numcopies, it does not. Arguably it ought to. But, sync does not send files in order to satisfy numcopies, it only sends files to satisfy preferred content. And it's important that this transfer the same files as sync does, because it will probably be used in a workflow where the user sometimes syncs and sometimes satisfies, and does not expect satisfy to do things that sync would not do. (Also opened a new bug that also affects sync et all, not only this command.) Sponsored-by: Nicholas Golder-Manning on Patreon
17 lines
424 B
Haskell
17 lines
424 B
Haskell
{- git-annex command
|
|
-
|
|
- Copyright 2023 Joey Hess <id@joeyh.name>
|
|
-
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
|
-}
|
|
|
|
module Command.Satisfy (cmd) where
|
|
|
|
import Command
|
|
import Command.Sync hiding (cmd)
|
|
|
|
cmd :: Command
|
|
cmd = withAnnexOptions [jobsOption, backendOption] $
|
|
command "satisfy" SectionCommon
|
|
"transfer and drop content as configured"
|
|
(paramRepeating paramRemote) (seek <--< optParser SatisfyMode)
|