Future breaking changes in libgit2 v2.0 #6988
Replies: 2 comments 8 replies
-
|
Note that one thing that was mentioned in #6191 was the idea that carrying around larger 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: typedef struct git_sha1_oid {
/** raw binary formatted id */
unsigned char id[GIT_OID_SHA1_SIZE];
} git_sha1_oid;
GIT_EXTERN(int) git_sha1_blob_lookup(
git_blob **blob,
git_repository *repo,
const git_sha1_oid *id);
...
int git_sha1_blob_lookup(git_blob **out, git_repository *repo, const git_sha1_oid *id)
{
git_oid proxy;
proxy.type = GIT_OID_SHA1;
memcpy(&proxy, id->id, GIT_OID_SHA1_SIZE);
return git_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:
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 turn off SHA256 support when they build to avoid those wasted bytes if they think that it's meaningful to them. (Basically inverting the |
Beta Was this translation helpful? Give feedback.
-
|
One concern I have with SHA256 support is performance. In my code for constructing a commit history, I found that 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? |
Beta Was this translation helpful? Give feedback.
-
|
Interesting - I think that I misunderstood. You're saying that you saw a slowdown in |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. I've been digging in to the optimizations that clang is doing; I naively assumed that gcc and clang optimized roughly equivalently on arm64 and also did a reasonably poor job building a microbenchmark for this in the first place. I'll investigate and will ship a v1.9.1. |
Beta Was this translation helpful? Give feedback.
-
|
It looks like you made this switch here — Uncommon/Xit@738ca60 — I'm curious if you happen to remember any more details? I ask because I'm having a bit of trouble replicating your report. Digging a bit deeper - here: https://github.com/Uncommon/Xit/blame/e7ac31506a7666cedf2021dba00f5ed2a21e1d69/Xit/Repository/OID.swift you were using a custom wrapper over It looks like here: https://github.com/Uncommon/Xit/blame/9b05de72d0bcf9da4447e566ff88474c430ddc2d/Xit/Repository/OID.swift you started using and here: Uncommon/Xit@738ca60 you moved back to a When I run a few million I'm not surprised that libgit2 v1.5.0 was 2.5 years ago. Any chance you were still using an x86 Mac then? I wonder if there are more obvious differences on x86 than arm. I can poke around at that hypothesis tomorrow. |
Beta Was this translation helpful? Give feedback.
-
|
I'm pretty sure I've had my M1 Mac for longer than that. What I recall is that I saw |
Beta Was this translation helpful? Give feedback.
-
We expect libgit2 v1.9 to be the last release in the libgit2 v1.x release line. libgit2 v2.0 will include a number of breaking changes.
SHA256 support
SHA256 support will graduate from "experimental" to be a supported part of the library. This will include both API and ABI changes to support.
TLS v1.2 as a minimum
libgit2 will remove support for HTTPS versions prior to TLS v1.2 and will update to the "intermediate" settings documented by Mozilla.
libtool-compatible SONAME versioning
Beginning with libgit2 v2.0, we will use SONAME versioning standards that align with libtool versioning requirements. Meaning, we will update the SONAME major version number on incompatible ABI updates. In addition, we will attempt to keep more ABI compatibility between minor versions of the library.
Removing the chromium zlib built-in
We will remove the ability for our cmake build system to compile a chromium zlib implementation in the "deps" directory. Users are welcome to build against chromium zlib, but should build it separately from libgit2, then link against it.
Removing the libssh2 embedded build system
Similarly, we will remove the ability for our cmake build system to compile libssh2. Users are welcome to build against libssh2, but will need to build libssh2 separately from libgit2, then link against it.
WinHTTP deprecation
WinHTTP will no longer be the default HTTP provider for Windows, and will be deprecated for behavioral compatibility across operating systems.
Object type cleanup
The
git_object_tenum contains items likeGIT_OBJECT_OFS_DELTA, which is not an object type, it's a descriptor of an item in a packfile. Similarly, the APIgit_object_type_islooseis nonsensical. The former should not exist, and the latter will be updated to talk about type validity.Beta Was this translation helpful? Give feedback.
All reactions