There exists a method (*Repository).ResolveRevision which satisfies part of the behavior of rev-parse, including resolving the relative operators (like ~, ^, etc.) but it is missing support for other basic scenarios (like the ones you describe).

@mcuadros was the intent that the internal/revision package would implement the full gitrevisions spec? If so, I think we want to add support for full and short hash literals as well as reference name disambiguation.

There are a handful of other gitrevisions that require broader feature support which is currently missing in this library. For example, reflog and upstream revisions.

any update?

@orirawlings the goals is cover all the cases. So will be great if any wants to implement it.

This case a891109d49d61fc0792912f0d741b45ec1516525 isn't taken in account, I didn't implement it, but I think it won't be that hard.
Those 2, refs/heads/branch and refs/tags/tag work actually, I tried with a repository of mine and it's resolved with the right sha .
Those cases heads/branch, branch and tag are bugs, I tried, they are correctly parsed as Ref but they are not resolved in the right way afterwards, I need to check why to fix that.

@mcuadros this issue needs to be reopened, this case a891109d49d61fc0792912f0d741b45ec1516525 is not covered yet, I'm working on it.

Also are you planning to cover short hashes?

Yep I'm going to do so as well

@antham any progress on shorthand hashes ?

@andreimc I had some trouble to have a good solution for this problem and left it aside the time to think about it and find something better, time flies.... Let me recheck this week.

After some search, I think it would be necessary to do something with the layer that interact with git directly, at a upper level we only handle full hash and as I see we can only iterate over commit which is very slow