Note that one thing that was mentioned in#6191 was the idea that carrying around largergit_oids that support SHA256 is wasteful for SHA1 repositories. This is, of course, true, but not something that we've addressed for v2.0.

I want to be a bit more concrete about this need and use cases before I write any code, but one can imagine something along the lines of:

typedefstructgit_sha1_oid {/** raw binary formatted id */unsignedcharid[GIT_OID_SHA1_SIZE];}git_sha1_oid;GIT_EXTERN(int)git_sha1_blob_lookup(git_blob**blob,git_repository*repo,constgit_sha1_oid*id);...intgit_sha1_blob_lookup(git_blob**out,git_repository*repo,constgit_sha1_oid*id){git_oidproxy;proxy.type=GIT_OID_SHA1;memcpy(&proxy,id->id,GIT_OID_SHA1_SIZE);returngit_blob_lookup(out,repo,&proxy);}

Similarly, for things that return or write to OIDs, we could do the opposite translation. This seems straightforward (and something we could probably even produce mechanically.) One could even imagine that you could do some dynamic loader trickery so that this "just works", but I'm not sure if that really makes sense. (It sounds complicated to me, and potentially brittle.)

There are a couple of issues here:

1. It's not clear where this code should live. One could imagine that it lives within libgit2, a sidecar library that we provide, or even the caller's code. If there's broad need for this, then we should ship it; if not, it's probably not worth us investing in.
2. More importantly,what do we do about callbacks? There are a handful of callbacks that give object IDs to callers. Presumably if you're using this odd API then you're all in ongit_sha1_oid or whatever we call it. I'd want to give yougit_sha1_oid in your callbacks as well. That's a little trickier; we could certainly build out proxies for all the things, but, meh.

Anyway. This is certainly possible, and I definitely want to give people the opportunity to save precious bytes. But without a clear need and a user who wants to help design this (or, better, help code it) then I'm going to hit pause ⏸️ here and say that we have an idea of what we would do, we're just waiting for the demand.

In the meantime, I intend to give people an opt-out to turnoff SHA256 support when they build to avoid those wasted bytes if they think that it's meaningful to them. (Basically inverting theEXPERIMENTAL_SHA256.)

One concern I have with SHA256 support is performance. In my code for constructing a commit history, I found thatgit_oid_equal() was a bottleneck: even when building withGIT_EXPERIMENTAL_SHA256 turned off, the switch statement ingit_oid_size was an extra step that could really add up in large repositories. I ended up just callingmemcmp directly, but this of course won't work once I actually need SHA256 support.

Is there a way we can have an approach where libgit2 knows that it's a SHA256 repo to begin with, and doesn't need to constantly check?