Revision Parsing

[kalkin]

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!

[Byron]

Thanks for starting a conversation. Is there code to look at that could be shared here?

Ok, but the main interaction point for the user of the library would still be Repository::rev_parse()?

Ultimately it will end up in git-repository, even though the abstracted implementation lives in git-revision. There it won't have access to git-ref or git-odb for example, so most transformations as instructed by the parser (or interpreter?) have to be handled by some sort of delegation mechanism.

[kalkin]

Is there code to look at that could be shared here?

Here you go https://gist.github.com/kalkin/507cb07aa37b4c9c6fd2ed04706336c0 . Entrypoint is pub fn parse_revision

[kalkin]

About the callback parser. I finally figured it out. You mean like XML-Parsers which use Visitor Pattern + Callback?
I don't think this is a good match for this kind of situation.

There it won't have access to git-ref or git-odb for example, so most transformations as instructed by the parser (or interpreter?) have to be handled by some sort of delegation mechanism.

Probably export a trait which needs to be implemented by Repository. I started working on this.

[Byron]

About the callback parser. I finally figured it out. You mean like XML-Parsers which use Visitor Pattern + Callback?

That's correct.

I don't think this is a good match for this kind of situation.

Did you mean to say that you do think it's a good match? Just because you are proposing to implement exactly that using a trait and started working on this.

I do recommend to share results in a draft PR early for feedback or alternatively implement it in your crate first the way you prefer it and we can migrate it. The reason is that gitoxide has a distinct style for a reason and it's not trivial to get the right from the start, so early guidance is usually advisable.