On Wed, Sep 03, 2025 at 03:10:44PM -0700, Junio C Hamano wrote: > Patrick Steinhardt <ps@xxxxxx> writes: > > Note that I'm not saying that we need to have both a C and Rust > > implementation for everything written in Rust. I don't think that's > > sustainable in any way. But any feature written in Rust should be a > > _new_ feature that can be disabled and that users can live without for > > the time being. > > Yes, if we can find such modular niche, it would be ideal. But how > many areas that we can cleanly plug an optional thing in without > disrupting existing codebase are there? Offhand, all I'd think of > are a new merge backend, a new rebase backend, a transport helper, > or perhaps a new diff-algorithm? Not too many, I guess. If we cannot find anything, an alternative could also be to take a very simple subsystem that doesn't see a lot of changes and convert that to Rust. We'd retain both implementations in that case, which I mentioned is painful because we now have to keep both in sync. But if we say that this is a testballoon, only, and that we don't continue to convert other code until Git 3.0, then that might be fine. "varint.c" could be a good match. It's trivial, only 30 lines of code, and completely standalone. We could still build new and optional functionality via Rust, but I guess it also doesn't hurt to have a test balloon that is part of libgit.a to test interoperability. I'll send patches later today. Patrick
