Closed
Description
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.
Parsing would go into the git-revision crate…
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 structureThis 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):
- Input contains
@{
→parse_with_at()
([<refname>]@{reflog}
spec NIY) - Input starts with
:/
→search_by_regex()
(NIY) - We have a revision of form
<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}'
- Split in to
<rev>
,<nav>
&<special>
parts. - Convert
<rev>
toId
- If
<nav>
not empty navigate - Apply
<specials>
NIY - PROFIT!
Metadata
Metadata
Assignees
Labels
No labels