Closed FintanH closed 1 year ago
Good point about namespaces; we aren't using them in the new protocol!
When I was working on the PR, I was wondering what are the best examples of git-ref-format
's benefits? I understand the points in its doc page, but it is not clear to me how much benefits it brings to overweigh the cost.
When I was working on the PR, I was wondering what are the best examples of
git-ref-format
's benefits? I understand the points in its doc page, but it is not clear to me how much benefits it brings to overweigh the cost.
What are the costs you refer to here?
The benefits are:
RefStr
/RefString
are valid references, Qualified
is a valid reference that begins with refs/<category>
, Namespaced
is a valid reference that begins with refs/namespaces
, and PatternString
/PatternStr
are valid refspecs. This is opposed to haphazardly passing around strings that we hope are correct. Another way of thinking about this is, "Parse, Don't Validate"git-ref-format
in important places such as git-storage
, radicle-cob
, and radicle
. That means that those libraries will already passing around and returning types from git-ref-format
.Thanks. The costs I was referring to are fallible constructions of types in git-ref-format
.
Closed via #48
radicle-surf
, historically, defined its own domain of reference types. This has, historically, caused some headaches for converting from surf types intoradicle-link
types. Now thatgit-ref-format
is available to surf, we should plan out the conversion of the API to use those types instead.Some things to consider:
Qualified
, ie. have a category likerefs/heads
,refs/tags
,refs/remotes
pub struct Tag(Qualified)
, with smart constructors