-
Notifications
You must be signed in to change notification settings - Fork 695
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
Augment getTagByName
to include getReferenceCommit
#403
Comments
is it just me, or are all of the getTagByName/getTag/GetBranch/getReference/getBranchCommit methods a bit inconsistant. Seems like they should be normalized a bit, so they all have a getType/getTypeByName/getTypeCommit/getTypeCommitByName variant. as it stands, getTagByName doesn't need to include getReferenceCommit, since the things returning commits are named get{type}Commit, not get{type}. I'll set about normalizing them all a bit, if nobody has any complaints. |
Yeah that's a great idea. On Thu, Feb 19, 2015, 9:58 AM Max Korp notifications@github.com wrote:
|
So a bit of an oddity here, we have to remember that "tags" are annotated tags, which are different from lightweight tags, which are what you usually think of when saying tag. Lightweight tags, references in general, branches etc don't have "oids" per se, just the targets and names. Only annotated tags have oids, because they exist inside of the object db. Annotated tags can also point to like, pretty much whatever you want. Do we want to rename tags (in the sense of annotated tags) to annotatedTag to make things clear? |
I don't know about this. That would be a pretty serious deviation from how we have historically done things with libgit2 (i.e. don't rename groups/classes). I like your previous method more. |
Yeah, just the previous method doesn't exactly make sense, TBH, since only annotated tags have an oid of their own. I suppose we could do |
All of those will point at a commit. |
No description provided.
The text was updated successfully, but these errors were encountered: