Please upgrade git2 to 0.19.x

[alerque]

https://github.com/martinvonz/jj/blob/27d8198fa1a020cd84da490df54a0d8eebd27b9e/Cargo.toml#L52

The current supported dependency is for git2 0.18.x, which is not the latest release and prevents linking against the current version of libgit2 provided by some systems. This is a bit of a problem for Arch Linux packaging. I'll work around it temporarily by vendoring, but this isn't ideal or what is expected our our packages.

[ilyagr]

Working on it, #4080.

[alerque]

Nice. And I searched for libgit2 in issue/pr titles even though I know the relevant crate was git2. Oops.

[thoughtpolice]

Does Arch Linux allow multiple versions of a package with different names, like some distros do for llvm? e.g. libgit2-18 and libgit2-19 or something? Homebrew does this, for example. If vendoring is the only option, is there any way for us to apply for an "exception" like this so that libgit2 will be vendored for us going forward? (Note I'm only asking if it's possible, not that you do this for us!)

The reason I ask isn't to downplay this ticket — actually, libgit2 1.9 has some features that we want — but because there is an underlying tension that won't go away just from fixing this particular bug. I recently made the argument here that realistically speaking, there is no reality in which anything but the version of libgit2 we specifically test and develop against should ever be used or distributed to users. It is very very very important that libgit2 behavior is at the very least consistent and understood. Every dependency has a cost, a risk and a reward, and this is the most critical dependency in the chain for an incredibly critical user-facing feature.

Practically speaking, this means we must be responsible for and, in a way, own the behavior of libgit2 — all its faults, its bugs, and its features — even if the developers are literally different group of people. The buck stops with us, in my mind.

Looking forward, in the long term we want to e.g. target Debian stable as a common denominator for dependencies — and it's very likely that will lead to cases like this again, where we want to target and use and a version of libgit2 that may be old compared to other distros and they want us to upgrade or something. Or maybe the opposite; we use a version of libgit2 that isn't in Debian, so they have to vendor it. In fact, I may even soon propose to re-vendor libgit2 in the Nixpkgs jujutsu package for exactly these reasons (note that I'm the maintainer of that package, and Nix has more flexible policies and safeguards than most other distros regarding these topics.) I am loathe to start supporting a matrix of libgit2 versions if at all possible because it will become very annoying for us and very confusing for users, not to mention distributors who now have to deal with this.

I think we'll upgrade to libgit2 1.9 soon enough and this won't be a big deal right now. But I'm afraid this kind of issue is going to rear its head again and the next time we do an upgrade. So, talking and thinking about it openly now is a good idea IMO if other maintainers are involved. (Please feel free also to tag-in other Arch/any distro maintainers who may have experience or opinions here!)

[emilazy]

We really need to get push support into Gitoxide so we can benefit from distributions’ more lax policy on Rust crate versions 🫠

(Well, and also just, probably, better backwards compatibility.)

[ilyagr]

We really need to get push support into Gitoxide so we can benefit from distributions’ more lax policy on Rust crate versions 🫠

(Well, and also just, probably, better backwards compatibility.)

We might, actually, get some help from the Git team itself: https://lore.kernel.org/git/[email protected]/T/#t

[dbarnett]

So is this fixed now? #4080 is merged.