Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Revision Parsing #408

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kalkin opened this issue May 12, 2022 · 0 comments
Closed

Revision Parsing #408

kalkin opened this issue May 12, 2022 · 0 comments

Comments

@kalkin
Copy link
Contributor

kalkin commented May 12, 2022

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 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):

  1. Input contains @{parse_with_at() ([<refname>]@{reflog} spec NIY)
  2. Input starts with :/search_by_regex() (NIY)
  3. 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}'
  4. Split in to <rev>, <nav> & <special> parts.
  5. Convert <rev> to Id
  6. If <nav> not empty navigate
  7. Apply <specials> NIY
  8. PROFIT!
@kalkin kalkin mentioned this issue May 12, 2022
2 tasks
@Byron Byron mentioned this issue May 12, 2022
3 tasks
@GitoxideLabs GitoxideLabs locked and limited conversation to collaborators May 12, 2022
@Byron Byron converted this issue into discussion #412 May 12, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant