Did you look at the etckeeper link I shared? Your question is sort of like asking “Why do they need wget/curl on the NonStop machine” or “Why do they need SQLite on the NonStop machine”.

Git is a useful general-purpose versioned data store and rsync-like network client in these situations… like a filesystem-agnostic version of ZFS’s ability to take snapshots and send/receive them over the network.

It might be educational for the audience to list out these programs

git, like many command line tools, turns git foo into an invocation of git-foo. Furthermore, commands are split into two categories: “plumbing” commands which do low-level things, and “porcelain” commands which are intended for end-users.

My understanding is that in the old days, various commands tended to be distributed as literally individual programs, but more recently, they’ve rolled them up into a single executable. This has been called the “lib-ification”, as mentioned in the mailing list thread.

Regardless, the main three implementation languages have been C, perl, and shell. For example:

• git commit: https://github.com/git/git/blob/master/commit.c
• git mergetool: https://github.com/git/git/blob/master/git-mergetool.sh
• git send-email: https://github.com/git/git/blob/master/git-send-email.perl

The discussion from the list about this idea, which you can see all on one page here: https://lore.kernel.org/git/ZZ77NQkSuiRxRDwt@nand.local/t/#u

Thus, Git should probably follow the same approach of not converting the already existing code, but frankly, I don’t see what would actually be the “new leafs” written in Rust.

One response:

In addition to some of the examples Junio mentioned elsewhere, I think new toplevel commands, like git-replay, would qualify.

Why the blatant bad faith?

Sounds awful. Where are there examples of this?

I’m not sure this is an entirely fair way of thinking about it. There are a lot of Rust developers who see Rust as a tool to solve problems instead of a prescription worldview.

Not to mention, there’s not that much need to be worried about interoperability if it’s file format based.

OTOH if the Rust version works out, and will be easier to extend, then maybe the original git will have to catch up with features? :)

That’s arguably already happening, with Jujutsu.

I’m at the untangling phase of this also :D

Yeah - the context I’m looking at is just the way the code parses hashes into a value. E.g. https://github.com/git/git/blob/e83c5163316f89bfbde7d9ab23ca2e25604af290/read-cache.c#L13-L80 Just using Digest::from_str(…) works much nicer.

But even if you rewrite it, the rust code is just better.

    impl FromStr for Sha1 {
        type Err = ParseSha1Error;
        fn from_str(s: &str) -> Result<Self, Self::Err> {
            if s.len() != 40 {
                return Err(ParseSha1Error::InvalidLength);
            }
            let sha1 = [
                u32::from_str_radix(&s[0..8], 16).map_err(ParseSha1Error::InvalidHex)?,
                u32::from_str_radix(&s[8..16], 16).map_err(ParseSha1Error::InvalidHex)?,
                u32::from_str_radix(&s[16..24], 16).map_err(ParseSha1Error::InvalidHex)?,
                u32::from_str_radix(&s[24..32], 16).map_err(ParseSha1Error::InvalidHex)?,
                u32::from_str_radix(&s[32..40], 16).map_err(ParseSha1Error::InvalidHex)?,
            ];
            Ok(Sha1 { bytes: sha1 })
        }
    }

It’s unclear that Rust is the only (or even best) way of providing this

It hopefully won’t remain true forever, but in 2024 Rust is by far the best language to write new systems like Git in. If you were starting a new source control project today, it would be a mistake to use anything other than Rust.

The calculus for existing systems is more complicated, but the desire to write Rust isn’t coming out of nowhere. Rust has a multi year track record of delivering dev tools that are very fast and very high-quality, with great support on both Windows and Unix platforms.

I started writing Rust professionally in 2017, when that track record didn’t exist. But in the systems communities I was in which tended to be both experienced and forward-thinking, it was quickly becoming clear that Rust was going to become the dominant systems language within the next 10-15 years. These were long-time kernel and systems hackers who were getting quite fed up with C and C++. I was still relatively junior then, and I’m quite glad I paid attention to them!

or even better fit-for-purpose languages like Zig

No, Zig doesn’t have memory safety as a core property, and it is not as good a fit as Rust for writing systems where correctness is non-negotiable, like source control. (It is also significantly less mature than Rust.)

I have written and shipped a large body of source control code in both C and Rust.

it is a hell of a lot easier for a Rustacean to get the basics of C than the reverse.

The basics are not enough to write C correctly and to a modern standard (no memory safety issues, no UB, takes advantage of multi core processors). I don’t believe humans can write C to a modern standard 100% of the time even with a lifetime of training, while writing Rust to that standard can be done with a few months of sustained learning.

Speaking more personally, I have no real interest in ever writing or contributing to a C project again unless I’m getting paid to do so.

Logically speaking, I think you’ve got this somewhat reversed: it would seem that we’re unlikely to get up the S-curve unless people get working on their platform.

No, it is far more likely that platforms that don’t support Rust will simply stop getting new software.

It’s unclear that Rust is the only (or even best) way of providing this

I don’t see anybody pushing for Rust at the expense of other ways to improve Git ? Some people think Rust will help and are pushing for it, no absolutist view needed. Git is a pragmatic project and has always been multilingual, I’m sure if other languages or big changes get suggested, their pros and cons will get discussed as well.

C […] does have a lot of existing users and maintainers

So does Rust (SO, /DATA, GitHub PRs). It’s not the only language that could be used to improve Git, but it’s arguably the most popular one.

it is a hell of a lot easier for a Rustacean to get the basics of C than the reverse

The problem is that you need much more than the basics of C to productively contribute to Git. It may have clean code, but it’s a complex project with huge QA requirements. I’ve onboarded trainees into projects in many languages, the level of proficiency required to not break a codebase is much higher in C than in Rust. If somebody is new to system programming, I’d rather teach them about the pain of borrow checking than the horrors of UB.

we’re unlikely to get up the S-curve unless people get working on their platform

This story demonstrates otherwise: projects are considering the use of Rust despite the trouble it can cause for niche platforms. Git might eventually decide to cancel (or heavily postpone) the transition, but other projects will go ahead (many already have). For better or worse, niche platforms need Rust more than Rust needs niche platforms.

Rust upstream has a m68k-unknown-linux-gnu target, getting a macos-classic target would be a fair amount of work, but it’s not unsatisfiable.

At some point, if you maintain an ancient platform, you have to decide whether you put in the work to bring modern software to it, or if you treat it as a museum piece. You can’t ask the rest of the world to stop evolving.