mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

add annex-proxied

Browse source 
This makes git-annex sync and similar not treat proxied remotes as git
syncable remotes.

Also, display in git-annex info remote when the remote is proxied.
This commit is contained in:
Joey Hess 2024-06-24 10:13:13 -04:00
parent 0c111fc96a
commit b8016eeb65
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
7 changed files with 31 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

9
doc/git-annex.mdwn
View file

@ -1674,6 +1674,15 @@ Remotes are configured using these settings in `.git/config`.
After configuring this, run [[git-annex-updateproxy](1) to store
the new configuration in the git-annex branch.
* `remote.<name>.annex-proxied`
Setting this to "true" indicates that a remote is proxied via the
git-annex repository that its remote points to. That prevents commands
like `git-annex sync` from pulling and pushing the remote.
Usually this is used internally, when git-annex sets up proxied remotes,
and will not need to be set.
* `remote.<name>.annex-cluster-node`
Set to the name of a cluster to make this remote be part of

12
doc/todo/git-annex_proxies.mdwn
View file

@ -26,17 +26,17 @@ In development on the `proxy` branch.
For June's work on [[design/passthrough_proxy]], remaining todos:
* `git-annex sync` etc should not treat clusters as git syncable remotes.
* On upload to cluster, send to nodes where it's preferred content, and not
to other nodes.
* `git-annex sync` etc, when operating on clusters, should first
* `git-annex sync --content` etc, when operating on clusters, should first
operate on the cluster as a whole, to take advantages of fanout on upload
and mass drop. Only operate on individual cluster nodes afterwards,
to handle cases such as a cluster containing a key, but some node
wanting and lacking the key. Perhaps just setting cost for nodes slightly
higher than the cluster cost will be enough?
* On upload to cluster, send to nodes where it's preferred content, and not
to other nodes.
higher than the cluster cost will be enough? Or should it even send a key
to a cluster node if the cluster contains the key? Perhaps that is
unnecessary work, the cluster should be able to rebalance itself.
* Getting a key from a cluster currently always selects the lowest cost
remote, and always the same remote if cost is the same. Should