In add --json-progress support in push and pull
I noticed that it might be good to have a git-annex put command
that is symmetric with git-annex get. That is, it picks which
remotes to send content to.
One use case is emulating git-annex push but with json output.
When operating on a single remote, that can be done using copy --to:
git-annex copy --auto --json --to $someremote
git-annex drop --auto --json --from $someremote
git-annex push --no-content $someremote
But to operate on all remotes needs git-annex put:
git-annex put --auto --json
git-annex drop --auto --json
git-annex push --no-content
So git-annex put would default to putting to all remotes,
but with --auto would honor preferred content and numcopies.
It's essentially git-annex copy --to run over each remote in turn.
Another way to look at it is this tower has a missing leg:
assist
|
--sync--
| |
push pull
| |
copy --to copy --from
| |
get
--Joey
git-annex getpicks which remote to use, and falls back as needed to another remote if the first is not available, and of course does nothing if the content is present already.It would be perhaps most symmetric with that if
git-annex putpicked one remote to send content to (ie, the lowest cost one that wants it), fell back to the next best remote if that one was not available, and avoided sending any content for files that are in some other repository already.As well as just being symmetric, that feels like a useful behavior that is not currently possible to get from any git-annex command.
That's in tension with the idea that
git-annex put --jsonwould send to the same remotes thatgit-annex pushwould. Maybe that behavior should be an option? Or maybe that belongs in yet another command.Just how useful would the 1 copy behavior be? One indication maybe is that noone has ever asked for that behavior. And it seems like it would be easy for the content to go to an unexpected place and break a workflow. Eg, suppose a user starts using
git-annex put, which sends the content tooriginand makes it available to others. But they also have a remote for a local USB drive, which has been disconnected all that time. When they one day reconnect that drive, it has a lower cost, and so their puts start going there, preventing others from accessing the files.Also it's worth noting that
pullpicks a remote to get to, butpushsends to all remotes that want it. So this particular symmetry is not maintained all the way up. So perhaps it's not a useful symmetry.Overall, it seems like something that could be an option and not the default. If someone has a good use case.