Does anyone with insight into Git development know if we should care about this? Is this just a proposal out of nowhere from some rando or is this an idea that a good portion of Git contributors have wanted?
It's to a "test balloon" if you have a plan to mandate it and will be announcing that. Unless I suppose enough backlash will cause you to cancel the plan.
Maybe I'm just old and moany, and I need to step aside for bigger and better things such as Rust.
But.
Now rather than needing to understand just C to work on Git/kernel, you now need to also know Rust. The toolchain complexity is increasing, and the mix of these languages increases the barrier to entry.
I'm highly invested into Git, having learned the tooling and having a significant number of projects constructed within it. I've written my own Git clients and have built a web server around Git repositories. I don't want to lose the hack-ability of Git.
Given that rust only works on e.g. cygwin recently (and still does not build many crates: i try to compile jujutsu and failed), this is a big blow to portability IMHO. While I try to like rust, I think making it mandatory for builds of essential tools like git is really too early.
I am curious, what is the reason behind introducing Rust in Git?
I am not familiar with Git development, I am just a user. But my impression is that it is already a complete tool that won't require much new code to be written. Fixes and improvements here and there, sure, but that does not seem like a good reason to start using a new language. In contrast, I understand why adding it to e.g. Linux development makes sense, since new drivers will always need to be written.
Developers who work on git think it will help them do their jobs better. Do you need any more reasons beyond that? They don't need to justify it to users necessarily.
The whole point of Rust is that C, and all the code written therein (or as much as is feasible), be eventually replaced and abandoned. The potential costs of continuing to use C, and all the memory and concurrency bugs that come with it, runs in the billions worldwide if not more.
Besides which, in 2025 all the real ones are using jj, which is 100% Rust, not git—so if git wishes to remain competitive it needs to catch up.
Is this a bit of chickens coming home to roost as far as developer culture forgetting how to work with cross-compiling toolchains? When I started my career, it was common understanding that the developer may be manipulating sourcecode on a different system and/or platform than where it will be executed.
Our source control, editing, compilation, and execution was understood to happen in different computational spaces, with possible copy/staging steps in between. You were doing something very naive if you assumed you could execute the built program on the same system where the sourcecode files existed and the editor/IDE was running.
This was a significant fraction of the build rules we used to manage. E.g. configuration steps had to understand that the target platform being measured/characterized is not the same as the platform executing the build tools. And to actually execute a built object may require remote file copies and remote program invocation.
This series was in response to another thread [1] which wanted to make rust mandatory in an upcoming release.
The authors proposal was to instead take the middle ground and use rust as an optional dependency until a later point of time where it becomes mandatory.
The later point of time was decided based on when rust support lands in gcc, which would make things smoother, since platforms which support gcc would also be included.
Rust suffers from the same problems that functional programming languages suffer from: deep learning curve and high complexity. The high complexity is intended to push more runtime errors back to compile time, but boy does that mean the language pays for it. Rust is a tire fire of complexity.
For these reasons I believe it is not a good idea. The kernel also sort of rejected Rust. The kernel is complex enough without adding a Haskell type system and a lisp-level macro system capable of obfuscating what code calls what code. serde code is so hard to spelunk for this reason. Contrast this with Go's Unmarshall, much easier to follow.
What's the point of trying to introduce Rust everywhere? Git is a mature piece of software and I doubt a lot of new code needs to be written. Also, Rust is very complex relative to C. If you really need classes, templates, etc, you can stick to C++ 98 and get something that is still clean and understandable relative to recent C++ standards and Rust.
37 comments
[ 2.4 ms ] story [ 57.6 ms ] threadPlease could someone elaborate on this.
Sounds like it will be mandatory to use Rust to build all of Git. The title implies Rust itself will be mandatory.
() am myself. Love rust. Hate rust rewrites.
From my (very limited) perspective, I just kind of thought git had settled in to 2.x and there wasn't any reason to break compatibility.
The beauty of the unsafety of C is partially that it's pretty easy to spin up a compiler on a new platform. The same cannot be said of Rust.
For example…had to build my own tool to extend git blame and track the AI generated code in our repository and save prompts:
https://github.com/acunniffe/git-ai
But.
Now rather than needing to understand just C to work on Git/kernel, you now need to also know Rust. The toolchain complexity is increasing, and the mix of these languages increases the barrier to entry.
I'm highly invested into Git, having learned the tooling and having a significant number of projects constructed within it. I've written my own Git clients and have built a web server around Git repositories. I don't want to lose the hack-ability of Git.
I am not familiar with Git development, I am just a user. But my impression is that it is already a complete tool that won't require much new code to be written. Fixes and improvements here and there, sure, but that does not seem like a good reason to start using a new language. In contrast, I understand why adding it to e.g. Linux development makes sense, since new drivers will always need to be written.
Can anyone explain what I might be missing?
Besides which, in 2025 all the real ones are using jj, which is 100% Rust, not git—so if git wishes to remain competitive it needs to catch up.
Ideally upstream git would become better as a library as part of being rewritten in Rust.
Our source control, editing, compilation, and execution was understood to happen in different computational spaces, with possible copy/staging steps in between. You were doing something very naive if you assumed you could execute the built program on the same system where the sourcecode files existed and the editor/IDE was running.
This was a significant fraction of the build rules we used to manage. E.g. configuration steps had to understand that the target platform being measured/characterized is not the same as the platform executing the build tools. And to actually execute a built object may require remote file copies and remote program invocation.
The authors proposal was to instead take the middle ground and use rust as an optional dependency until a later point of time where it becomes mandatory.
The later point of time was decided based on when rust support lands in gcc, which would make things smoother, since platforms which support gcc would also be included.
[1]: https://lore.kernel.org/git/pull.1980.git.git.1752784344.git...
For these reasons I believe it is not a good idea. The kernel also sort of rejected Rust. The kernel is complex enough without adding a Haskell type system and a lisp-level macro system capable of obfuscating what code calls what code. serde code is so hard to spelunk for this reason. Contrast this with Go's Unmarshall, much easier to follow.