This is planned, but not yet implemented. The idea for the current implementation of tags actually comes from an earlier implementation of cloning via SSH.
Good, add beta tag on it or close.
J6IA7KHTRJ55RE5UWR26OQAB4J64YYX3RU3XYU4M6JHRBJ2DHAZAC
C5B72K2QDXKEOZOYZNYWCX3S5QTFJHDGB6I5KLKZEMIIWFQYHXXQC
AIAWXAPQYNQQRUP3YYRWNSWXCW3SEY4VUCG6KDMUPUEYYZRYNRCAC
AIAWXAPQYNQQRUP3YYRWNSWXCW3SEY4VUCG6KDMUPUEYYZRYNRCAC
ZDK3GNDBWXJ2OXFDYB72ZCEBGLBF4MKE5K3PVHDZATHJ7HJIDPRQC
Sorry for all these changes, I believe it’s ok now.
The tag exchange feature I wanted turns out to be much harder than I expected, introducing a large number of potential security issues.
Explanations: tags are files containing a compressed version of the entire repository. In future version, I’m planning on using that to make pristines smaller and faster.
One idea to push, pull and clone tags would be to send these files over the network. However, this is a rather big can of worms to open, as users would either need to trust that the claimed sequence of changes yields that particular state, or spend large computing resources on recomputing the state, making tags rather useless from an algorithmic point of view.
I’m planning to release a less ambitious feature, where you can ask a remote to tag itself if they have the same current state as yours, and clone states. However, I don’t think tag files should be sent over the network yet, maybe in the future.
Alright, this is fixed now! One of the trickiest feature ever, I’ll explain it in a blog post very soon.
What if users would like get a
tag
via clonning of channel too?