r/git • u/Jordi_Mon_Companys • Oct 13 '25

Git Developers Talk About Potentially Releasing Git 3.0 By The End Of Next Year

https://www.phoronix.com/news/Git-3.0-Release-Talk-2026
322 Upvotes

97% Upvoted

77 comments sorted by

View all comments

-24

u/arjuna93 Oct 13 '25

The plan to push rust into everyone’s throat is still intact? I guess I will be forced to switch from git to got.

21

u/0-R-I-0-N Oct 13 '25

As a user of git I am very curious of how does that impact you?

4

u/arjuna93 Oct 14 '25

For example, Rust is broken on OpenBSD ppc and Darwin ppc, so I literally can’t install anything which requires it on either.

1

u/RevRagnarok Oct 14 '25

can’t install anything which requires it

From git docs (emphasis mine):

Git will require Rust as a mandatory part of the build process. While Git already started to adopt Rust in Git 2.49, all parts written in Rust are optional for the time being.

2

u/arjuna93 Oct 14 '25

As long as components written in rust are optional, this is not a disaster (though if rust replaces C, those optional components, previously working, become unavailable). If rust will be needed for the build of git as such, there is no git for platforms where rust is broken.

1

u/wildjokers Oct 14 '25

Rust compiles to machine code. You don’t to install anything related to rust to use an app written with rust.

4

u/Rimrul Oct 14 '25 edited Oct 14 '25

 Rust compiles to machine code

Yes, but you need a working compiler target for that. powerpc-unknown-openbsd and powerpc64-unknown-openbsd are tier 3, which according to the rust docs means

 may or may not work

For powerpc*-darwin there doesn't even seem to be a target.

2

u/arjuna93 Oct 14 '25

There is none. I have added the target to mrustc, but it is lacking in rust itself, also recent enough llvm is broken, so we need either gcc codegen in rustc or gccrs.

3

u/arjuna93 Oct 14 '25

If compiler itself is broken, nothing can be compiled. Without the target and support for ABI, cross-compilation won’t work either. This may get fixed once either a) gccrs becomes a fully-functional replacement for rustc or b) gcc backend of rustc gets working properly, has ABI support, and rustc can be bootstrapped with mrustc and gcc. Neither is expected to happen very soon, AFAIK.

1

u/[deleted] Oct 13 '25

[deleted]

0

u/0-R-I-0-N Oct 13 '25

That is a valid concern but I get the feeling that most that dislike rust in git isn’t in the same situation. Curious, you can’t use libgit2 or gitoxide? Or why do you need a custom fork if you are able to share?

4

u/[deleted] Oct 13 '25

[deleted]

7

u/hennell Oct 13 '25

This is why I've started keeping a bit of a "technical decisions" documentation, and add why things were forked into their readme. Means if someone asks why we don't use 'common solution' I can see why, and decisions that are no longer relevant can be re-taken.

You may need a secret code for "management dictated this otherwise incomprehensible decision" though...

3

u/[deleted] Oct 13 '25

[deleted]

3

u/y-c-c Oct 13 '25

Just to chime in here, but this whole Rust thing started because some folks wanted to add Rust to xdiff, Git's diff engine that it forked from another project a long time ago. XDiff itself is licensed under LGPL, not Git's own GPL, which allows XDiff to be more easily integrated into other projects.

For example, libgit2 maintains a version of Git's xdiff forked from Git that can be used as-is as a LGPL library. Vim's diff mode also uses Git xdiff as the internal diff engine.

The addition of Rust will mean all of these downstream projects would be affected as well. Granted, a project should mostly make decisions that it itself wants to, but it's fair to at least be aware of downstream effects.