Cross-post of Handle git tags · Issue #145 · radicle-dev/radicle-link · GitHub, where it should re-surface once the time has come
We have so far (deliberately) avoided to talk about how we should handle git tags.
Git has two types of tags: “annotated” and “lightweight”. Annotated tags are a type of object in the odb with the same shape as commit objects. Lightweight tags are merely pointers from
refs/tags/<tag> to objects. (Aside: note that both types may point to any object type, not just commits)
Lightweight tags are meant to be used locally (ie. not published), while annotated tags may denote releases or similar, and are supposed to be published alongside the code. So the former can be used mutably, but the latter shall not (although it’s possible, like anything in git).
The question now is, how do we handle them in a fully distributed setting?
Not allowing lightweight tags to be replicated seems to be the philosophically right thing to do, and is doable, albeit a bit annoying as we will have to inspect what a tag ref points to in order to be able to tell whether it’s a lightweight or annotated tag.
refs/tags category is global (ie. not namespaced by remote), annotated tags are trickier. There are four possibilities afaics:
This will leave git tooling intact, but violate workflow assumptions. External tools can no longer rely on tag names being repo-global, and maintainers would need to “merge” tags into their own
Keep them global, and use project ACL to decide who can tag
This means that if two maintainers create conflicting tags (ie. having the same name), one of them will be rejected (non-deterministically, first-seen-wins). A major complication is that we’d need to consider the maintainers-set as valid at tag creation time.
Invent a tag-agreement scheme
That is, a special type of “feed” (you know, like issues) which has some semantics attached to it, and would carry references to actual git tag objects (but not their refs) in the commit parents (hell yeah, that’s a hack). If consensus is reached, the tag refs would be created in the working copy .
Don’t allow tags at all
Since tags require coordination, and
radicle-linkdoesn’t provide coordination, you need to use some other system to reach consensus on your tags. This business is all in your working copy.