Timeline for release of version 2?

[lorenzleutgeb]

The release notes of 1.9.0 tease SHA-256 support in version 2:

This is expected to be the final release in the libgit2 v1.x lineage. libgit2 v2.0 is expected to be the next version, with support for SHA256 moving to "supported" status (out of "experimental" status). This means that v2.0 will have API and ABI changes to support SHA256, as well as other #6988.

Since then, 1.9.1 was released. Some downstream projects (rightfully) defer to libgit2 for any timelines on SHA-256, see, e.g.

• SHA-256 rust-lang/git2-rs#1090 (comment)

My attempts to find any hints about a potential timeline for version 2 failed, but I have to admit that I am not following development of libgit2 very closely.

I would like to kindly ask the developers on whether there is any timeline or not? A gut feeling might be enough. Thanks.

[EvanCarroll]

I'd also love to see this happen being downstream with git cliff and using forgejo which now supports sha256.

[Taywee]

Git 3.0 is planning on defaulting to sha-256 repositories. I assume they'll give a decent heads-up before that happens.

A little shocking, though, that GitHub doesn't even have support for sha-256 yet, when most of its competitors do.

[EvanCarroll]

I agree, but "shocking" is an understatement. Only because you brought up that absurdity will I add fuel to the fire. I've been trying to get them to fix this.

• Add objectFormat setting to allow init()ing a repo with sha256 actions/checkout#1945 (comment)
• More attention to open PRs (a year+ wo/ code-owner review?) actions/checkout#2289

There are patches at the action level that would solve this. They've been sitting on them for over a year. Moreover, @bk2204 is the Microsoft employee that both submitted the sha256 patches to git proper and he frequently gives talks about sha256. https://www.youtube.com/watch?v=OidS-YJxjeo (never met them, but I've heard great things about and them and I worked under their old boss -- people revere them like a saint).

So they got the best person for the job, and they got patches demonstrably ready with tests to commit.

Meanwhile, Microsoft is taking money to kill kids in Gaza with AI and contracting with CIA. I can't help but wonder if we're all insecure for a more pernicious reasons; and, I wouldn't it that all that shocking.

[Ericson2314]

I've heard a problem for the next release this is that @ethomson has gone silent? Is there anyone else that can cut the release? Are there other breaking changes that need to be merged together before 2.0?

I personally don't care about breakage at all --- I don't mind if 2.0 is released, then "whoops we need more breaking changes happens", so 3.0, 4.0, etc. are then released in quick succession. I understand if this is the minority view, but I mention it anyways, as it could take some of the pressure off for getting 2.0 "exactly right".

[EvanCarroll]

Generally, disagree. People should have time to perfect their craft and product. However, 100% of software development that stalls with patches in the pipeline have made a mistake. Always. That's a philosophical position that I believe is much more firm than agile development.

[Ericson2314]

To be clear, to me, major version churn means that craftsmanship is still possible. It's only the combination of rushing the ship and "can't do 3.0 right away" that inhibits craftsmanship, and that would be bad!

[malikwirin]

Motivated to create a list of downstream issues that all point to libgit2 supporting sha256 eventually

[Ericson2314]

Actually, that would be great if you can do that!

[malikwirin]

Actually, that would be great if you can do that!

Many of them are downstream issues of libgit2 because of rust-lang/git2-rs#1090
I can list some. I hope we can get a more complete list. While I thought I could name some more but issues like jj-vcs/jj#3813 actually depend on GitoxideLabs/gitoxide#281 which does not depend on git2-rs and libgit2.

• [BUG] Support sha256 repos cocogitto/cocogitto#412
• Support the sha256 git object format NixOS/nix#9980
• Support for sha256 git repositories zed-industries/zed#24070

[Taywee]

Not open in the repository, but the nushell gstat plugin also doesn't function in sha256 repositories because of its dependence on libgit2 at the moment. Most nushell users with git statuslines can't have them function in sha256 repos, because the majority of them use gstat.

[ethomson]

Motivated to create a list of downstream issues that all point to libgit2 supporting sha256 eventually

You're welcome to do that, but what would be more useful is if any - literally just one - of these downstream users tried the SHA256 support and reported anything - literally anything - about whether it works for them, or has issues.

If there are people that are suggesting that libgit2 having sha256 support is necessary for them - and they're not doing anything to use the sha256 support - then please encourage them to do so.

[Taywee]

That's a bit of a chicken-and-egg situation, especially with a library like this. Very many actual users are several steps downstream of libgit2, using it through a project that often uses a wrapper of libgit2. Many users care about sha256 support (or at least some users; will be many more when git defaults to it), but a lot of wrappers are taking a "not until it's out of experimental" position, so libgit2 (very reasonably) wants more downstream users before it takes it out of experimental, but lots of downstream users can't use it until it's out of experimental.

[Ericson2314]

@ethomson OK here is the draft PR NixOS/nix#14526

CI will just run the existing tests / I did not manual testsing. We would want to extend our test suite to cover both types of repos before shipping it. But at least we can already say switching to the experimental variant didn't cause any regressions. :)

I hope we can use this to break the chicken-and-egg situation.

[EvanCarroll]

You're welcome to do that, but what would be more useful is if any - literally just one - of these downstream users tried the SHA256 support and reported anything - literally anything - about whether it works for them, or has issues.

That's a fair request, but if that's what you're waiting for -- shouldn't we at least update the people who have put out the patches years ago that we're waiting for third parties rather than ghosting them entirely? That's the only problem here. I'll get you over a test in jiff. No problem.

[lorenzleutgeb]

Exactly why I suggested to allow accessing experimental support for SHA-256 in rust-lang/git2-rs#1090 over a year ago (via a feature flag, so that users can opt-in and report issues). And as the project I work on is downstream of the git2 crate, there isn't much I can do (without participating in git2 development myself). So from my perspective, this only leaves me to wish that git2 and libgit2 should be communicating with each other way more, for the sentiment to change from comments like rust-lang/git2-rs#1090 (comment) to communication with their upstream. I know that I am easy to dismiss as a bystander, but please just take this as a hint for more collaboration. We're stronger together.

[Ericson2314]

@ethomson How does the downstream PR I made look? What would you like to know?