git-annex sync has been split into push/pull, but there is another split
possible: git-annex sync --no-commit --no-pull --no-push --content.
That is a mouthful, so maybe it could be a separate command?
Actually, that used to sync content with older git-annex at least some of the time, but 2e984c51b65165e79c2fcd5212712ac4e73850de changed/fixed --no-pull and --no-push to also prevent syncing content. This new command would be the content-syncing part of sync only.
Also, such a command could be perhaps be more like git-annex get/drop/copy
in operating on the listed files or current directory and below by default.
Although that might make it difficult for it to handle sending files to
exporttree remotes, which sync does with seekExportContent which operates
on the whole exported tree.
What would be a good name for such a command? --Joey
How about
git-annex portas it carries content over like a luggage carrier aka. porter? Another one that comes to mind isgit-annex shuttlebut that could be semantically too similar togit-annex assist, perhaps. --jkniiv
It would also be awesome if there was something like
git annex synconlycontent --recentor--since=HEAD~10or--since="1 week ago"to just operate on the latest changed files. In contrast to--accessedwithinthis would look at the git history to check when files were touched. This is currently possible with something likegit diff --name-only | sort -u | xargs git annex ...orgit log --since=... --format... | ... | xargs git annexbut it's far from convenient.This might be a general new matching option for other subcommands as well.
git annex transferinto the ring for an alias forgit annex sync --content --no-commit --no-push --no-pull.@nobodyinperson open another todo for the --recent or similar idea. Something like that would be just another matching option. (However, getting and parsing
git log --sinceseems like it would be hard to do efficiently..)@nobodyinperson
git-annex transferis not bad. Although I was envisioning this also handling dropping content from repos that don't want it, same as sync does.Well, I suppose getting a file from a remote and dropping it from the remote can also be seen as a "transfer". Just because git-annex internally uses "transfer" specifically for copying an object around doesn't mean the command line interface has to.
How about
satisfy? It satisfies preferred content configuration.(Not numcopies configuration though, as implemented.)
git annex syncdoesn't satisfy numcopies, what does? Is numcopies just for drop/move?sync/satisfywon't override the preferred content to satisfy numcopies, right? Then my mental model ”git annex ensures there's always at leastnumcopiescopies of your files” wasn't really true. It just ”won't by itself reduce the amount of copies of a file below numcopies/mincopies”, right? If that's true, would a command or option to sync/satisfy make sense that enforces numcopies and potentionally overrides the preferred content?It won't send content that is otherwise not wanted just to satisfy numcopies. Of course, like all commands, it refuses to drop a file if numcopies is not satisfied.
Comsider a remote foo that only wants
include=foo/*. And another remote bar that wantsinclude=bar/*. And numcopies=2. Ifgit-annex satisfywas only able to access foo, and worked to satisfy numcopies, foo would end up with files in bar/* that it doesn't want. But there's a better place for those files to go, namly bar, which wants them. So over time it would do a large amount of unncessary work, sending files to foo, only to later drop those same files from foo once it was able to populate bar.If the user wants to, they can configure foo to want
include=foo/* or lackingcopies=1and thengit-annex satisfywill know this is a repository that wants any files that don't have enough copies, and when bar is not accessible, it will send its files to foo.I think this could stand to be better documented. Especially since things like
git-annex copy --autodo work to satisfy numcopies in addition to preferred content.Aah okay, I forgot there's
lackingcopies. So if one addsor lackingcopies=1to every (sensible) remote's preferred content, then git annex is allowed to put "fragile" files there which haven't been copied enough yet (until there eventually are and they're removed again). I was missing that link, now everything makes sense.And now I see that this is exactly what the
clientgroup does 😅