- 
          
- 
                Notifications
    You must be signed in to change notification settings 
- Fork 396
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