You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The goal of this issue is to implement parsing git revisions, according to gitrevisions(7). Parsing
of ranges is not a goal of this issue, but the first step. See also #XXX.
Ok, but the main interaction point for the user of the library would still be Repository::rev_parse()?
parse plain bytes (or &BStr), not &str
Ok, I can adjust that.
call functions to signal which item was parsed, that is it doesn't parse
into a data structure
This design makes it possible to validate by making each callback a no-op and
to produce the final object id step by step otherwise if a Repository instance
is providing the callbacks.
I'am not sure I understand what you mean. My approach does not parse into a
data structure. It works like this (no ranges support):
The goal of this issue is to implement parsing git revisions, according to
gitrevisions(7). Parsing
of ranges is not a goal of this issue, but the first step. See also #XXX.
To piggy back on the reply from @Byron from here.
Ok, but the main interaction point for the user of the library would still be
Repository::rev_parse()
?Ok, I can adjust that.
I'am not sure I understand what you mean. My approach does not parse into a
data structure. It works like this (no ranges support):
@{
→parse_with_at()
([<refname>]@{reflog}
spec NIY):/
→search_by_regex()
(NIY)<rev><nav>*<special>?
where<rev>
is SHA1, refname, HEAD or@
<nav>
is the^
or~
operator followed by an optional number<special>
is a type filter{tree}
, a peel tag command{}
or a regex `{/regex}'<rev>
,<nav>
&<special>
parts.<rev>
toId
<nav>
not empty navigate<specials>
NIYThe text was updated successfully, but these errors were encountered: