-
Notifications
You must be signed in to change notification settings - Fork 56
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
Need some kind of high level "rev-parse" functionality. #8
Comments
I really like the sound of this! My plan is to implement some high level "convenience" wrappers around the gitteh bindings once they're complete. I was planning on implementing these in JS. Your ideas for revParse would be a great first step! I like the idea of revParse processing anything - particularly if you give it any ref and it will automatically peel the ref (if it's symbolic) and load the commit. Not too sure about resolving fragment sha1's though - libgit2 doesn't support this. I guess we could scan the git repository on the filesystem and try that - but then we'd also have to scan packfiles too. |
What do you think if we made revParse just straight up retrieve the object you provide? In such a way that it retrieves For example:
|
@samcday Please, tag this as |
This would be a lovely feature. I'm using node-gitteh to implement a simple git-backed static file server, and supporting sha1 fragments in particular would be handy for short URLs. Revisions of the form "HEAD~1" would also be handy for comparing the latest and previous versions. |
Actually, a |
Revparsing is available in libgit2 |
It would be great to get some sort of "rev-parse" functionality that you could pass any revision identifier to and have it resolve to a SHA hash. Maybe something like:
Thoughts?
The text was updated successfully, but these errors were encountered: