I'm wary that the internal git_revparse() allocates a git_object, extracts the OID, and then frees the object, and then 99% of the uses of the API immediately reallocate the object. I realize that is partially because the old API returned an object so the existing code was using this function for those cases, nonetheless it seems odd.

I realize there has probably been quite a bit of discussion that I missed while I was on vacation, but is there a strong reason to remove existing the git_revparse_single() API (since it still exists internally alongside the new one) rather than just letting them coexist? I do like this new API better than the "rangelike" one - it seems like an API for "maybe a range" (such as this) and an API for "better be just one" could happily coexist without creating too much confusion.

I was mainly trying to reduce the surface area of this API, but I get your point – it's clunky for looking up one endpoint.

I'll add _single back in, and see what I can do to reduce object loading and freeing.

Okay, I reintroduced git_revparse_single, and made sure it barfs if you give it a range spec.

Also, I changed the new git_revparse call to use git_object * for its output parameters. I think this makes more sense than using git_oids, since revparse is pretty well expected to walk the object graph, so git_object is probably the most native type for it to think in.

Looking good to me.

It seems like there are so many cases where you just want to quickly look up a single object that I like keeping git_revparse_single as a separate API. (I'd rather remove some of the four git_oid string parsing APIs if we want to reduce related API surface! 😄)

Do you think this is merge-able? Since it's an API change and we're thinking about tagging a new release today, I feel like it would be nice to slip it in before tagging...

Yeah. It's a minor enough change, and built on code that's pretty solid and well-tested. I feel pretty good about merging it.

Superseded! Thanks ben!