On Thu, Sep 4, 2025 at 4:40 AM Patrick Steinhardt <ps@xxxxxx> wrote: > > On Thu, Sep 04, 2025 at 12:57:25AM +0000, brian m. carlson wrote: > > On 2025-09-03 at 05:40:54, Patrick Steinhardt wrote: [snip] > > Also, the approach of making it an optional component directly > > contradicts the proposed policy I wrote up. That's a recipe for > > additional burdensome work maintaining two implementations, when we > > actually want to make it easier for people to contribute functionality. > > It also doesn't provide any of the memory safety benefits or address any > > of the concerns from governments, security professionals, and other > > parties about the real and substantial risks of continuing to develop in > > C. > > The only reason why we want to have it as an optional component is to > make the transitioning period easier for downstream distributors. And > the intent is not to convert major components -- it should be trivial > components that we can use as test balloons, similar to how we did it > for all of our C99 test balloons. > > We cannot just pull the rug away under their feet without advance notice > that this is going to happen. I find this statement a bit problematic for four reasons: (1) "without advance notice" was already pointed out to be inaccurate in this thread, including in the exact email you are responding to; you could argue that there hasn't been _sufficient_ advance notice, but then there should be more details about what is and isn't sufficient. Merely repeating this claim which brian just barely pointed out to you as false almost feels dishonest. (2) "pull the rug away" seems hyperbolic. I would have liked some explanation as to how a transition period is expected to help, and how the existing transition period has been insufficient. You do hint a little at the former, which I'll discuss more in point 4, but you neglect the latter to the point of pretending it didn't exist. In short, why is a further transition period needed, and how will it differ from the existing one we've already had? It's not clear to me why distributors must immediately update to the latest git version. Taylor discussed this aspect in detail in this thread; you even responded briefly (and tangentially?), but still as far as I can tell presume the latest and greatest is mandatory for them to adopt without stating why. Maybe they do need to adopt the latest and greatest, but I haven't seen folks state why that's the case. Did I miss it? It also feels like Rust support is being lumped in with "breaking changes", which to me feels misleading. Historically, we have talked about breaking changes and deprecation periods and such so that users could adjust scripts or their command lines such that they would work across multiple versions of Git. The Rust case is somewhat different in that we're not discussing behavioral changes of git, merely implementation differences. If someone has both a C-only version of git and a newer version of git that was built with both Rust and C, any commands they run should behave the same as far as the C-vs-Rust goes (unless we have our normal discussions about specific behavior and any deprecations we want to do related to it, of course). I do agree that reduced platform support is a negative change (though Rust brings other advantages that may offset this downside depending on your viewpoint), but I don't see why it's a breaking change and especially not a "pull the rug away under their feet" change. (3) the use of "cannot" presupposes the policy stance which we are having a discussion about, which, whether intended or not, feels like an unfair way to attempt to shut down the conversation. (4) you suggest that adding Rust as an optional component should avoid the problem, yet we've already had Rust as an optional component for the last three releases, going back to 2.49.0. (libgit-rs and libgit-sys). In this case, you helpfully provided some details distinguishing the type of optional component you want -- the reference to a test balloon suggests you want an optional component that is turned on by default (but which users can easily turn off). Am I correct that this is your intention? If that's the case, then that's a useful distinction, but I think that distinction needs to be made a bit more clearly (and as a side effect, acknowledge that Rust has already been optionally shipped in some form, and was even specifically highlighted by GitHub's and GitLab's blog posts about the v2.49.0 release, among other places) > > For example, there is zero chance I will implement any of the > > SHA-1/SHA-256 compatibility code twice. I'm already doing that in my > > free time without any compensation at all and it's unreasonable to > > expect me to do it twice or even to #ifdef out all the places it would > > need to go. I am happy to let someone else take responsibility for the > > project instead, however, if they would like to do those things. > > And that's totally fair. From my point of view, this compatibility code > is a _new_ feature that we are adding to Git. And as I mentioned, I > think it is reasonable to say that new features may be implemented in > Rust now already, as platforms that aren't yet ready wouldn't lose any > existing functionality. Am I correct to understand that you're suggesting a policy where brian cannot modify any existing code to be written in Rust, and can only add new Rust code? Perhaps the SHA-1/SHA-256 compatibility code is just new code, or can be done with minimal changes to existing C code while adding new code. If so, maybe this is a workable solution for him. But if it can't be done with minimal changes to existing C code and this policy would impair brian's ability to deliver the compatibility code, then I think this policy would be unworkable. I really don't want to hamstring brian's ability to implement the compatibility code. It has sat dormant for years with no one else stepping up to the plate, it's a really important project, and brian has time and energy now. I don't want any chicken-and-egg problems introduced for him with the 3.0 release. Even though I've been working with Ezekiel on xdiff, and I'm obviously a bit biased in that area, I find the sha1-sha256 compatibility work to be more critical and something we should do everything possible to facilitate. > I think most or even all of the contributors are on board. But we never > really talked about timelines, or how we want to introduce Rust, so > that's a discussion we need to have now. Agreed.
