From: Sam James <sam@gentoo•org>
To: Elijah Newren <newren@gmail•com>
Cc: me@ttaylorr•com, ezekielnewren@gmail•com, git@vger•kernel.org,
gitgitgadget@gmail•com, sandals@crustytoothpaste•net,
Eli Schwartz <eschwartz@gentoo•org>
Subject: Re: [PATCH 0/7] RFC: Accelerate xdiff and begin its rustification
Date: Tue, 22 Jul 2025 22:55:30 +0100 [thread overview]
Message-ID: <87o6tbevql.fsf@gentoo.org> (raw)
In-Reply-To: <CABPp-BEf2O12jx-wN5ig941SyoL=X2OJkQY26bac=8+v+jx8ZQ@mail.gmail.com>
Elijah Newren <newren@gmail•com> writes:
> Hi,
>
> On Tue, Jul 22, 2025 at 9:03 AM Sam James <sam@gentoo•org> wrote:
>
> First of all, thanks to all the Gentoo folks for chiming in and
> providing specifics about platforms and their state.
Thanks. I've been trying to be very specific about what the issues
are. I don't deny Rust is the future of many projects, but it still has
rough parts, and I'd like to ensure they're discussed. It is not my
intention to just scream whenever someone considers adopting Rust.
>
>> > I am far from a Rust expert, but I think that a more modern, memory-safe
>> > language will attract newer contributors who may have a fresher
>> > perspective on the project, and I think that's a good thing.
>>
>> Aren't they likely to contribute to gitoxide? There, they get a clean
>> slate without having to deal with the least-fun part (bidings).
>
> I'm sure some are. But clearly there are others where the draw is
> improving git itself because of its installed base; in fact, we need
> look no further than this exact series we are commenting on to find
> proof of that -- one such new contributor submitted patches to use
> Rust in git, and found a significant speedup while doing so.
Part of my opinion there is coloured by how generally working on a
polylang codebase often has pain when dealing with bindings and the
edges, so I figure that anyone most-keen on Rust would surely want to
avoid that ;)
>
> Further, there's considerable interest from existing git developers to
> use Rust in git as well; last year at the Git contributor summit,
> usage of Rust in git was not only one of the topics of discussion, it
> was the top voted topic (meaning, the topic that the greatest number
> of git contributors wanted to discuss).
>
>> > It is also not the Git project's responsibility to ensure that every
>> > platform is Rust-friendly.
>>
>> That's true, of course. And nobody is entitled to indefinie updates, but
>> on the other hand, there's still some implicit contract with users. I
>> really don't think git would have the adoption it does today if it had
>> adopted a Rust-like language in the same state Rust is now from the
>> start.
>>
>> (In exactly the same way, git doesn't gratuitously break compatibility
>> every release either. Can it? Yes, and git can change the platforms it
>> runs on, but it's something to be taken seriously.)
>
> This feels kind of close to a false dichotomy between breaking
> compatibility every release and indefinite update entitlements. There
> is certainly some middle ground: discussing reducing the breadth of
> platform support in order to gain other benefits, then gathering
> feedback, making a plan, and announcing the upcoming change, etc.
>
Of course. I'm just making the point that it is indeed a compatibility
change, and perhaps that perspective is useful.
> And we're already pretty deep into it. Concerns about losing out on
> some platforms have repeatedly slowed us down from adopting Rust years
> ago. Yet, the desire for Rust adoption keeps coming up anyway; see
> the threads starting at
>
> * https://lore.kernel.org/git/ZZ77NQkSuiRxRDwt@nand.local/
> * https://lore.kernel.org/git/Zu2D%2Fb1ZJbTlC1ml@nand.local/
> * https://lore.kernel.org/git/20241128-pks-meson-v10-22-79a3fb0cb3a6@pks.im/
> (search for "Rust")
> * https://lore.kernel.org/git/cover.1723242556.git.steadmon@google.com/
>
> The discussion has also been picked up and reported outside the Git
> mailing list, e.g. https://lwn.net/Articles/998115/.
>
> And so, in addition to the optional contrib/libgit-rs and
> contrib/libgit-sys Rust components that have already been merged into
> git, and a new build system added in part to make it easier to adopt
> Rust, we now have the first patch series that proposes a hard
> dependency on Rust.
Yes, that's why it's of concern. I have no issue with the optional parts.
>
> Further, I'd like to comment a bit on the support of our users from
> another angle. We're also responsible for security for our users
Supply-chain issues become more of a problem with Rust if we end up
making heavy use of crates. A policy moderating their use is something
we should talk about.
> and
> feel Rust would help (see e.g.
> https://litchipi.github.io/infosec/2023/01/24/git-code-audit-viewed-as-rust-programmer.html
> and https://github.com/bk2204/git/commit/fbeb1180c7473635a964daed2da642c53487782d).
> We're responsible for performance of Git for our users, and feel Rust
> would help (see the email that started this thread,
> https://lore.kernel.org/git/CABPp-BFOmwV-xBtjvtenb6RFz9wx2VWVpTeho0k=D8wsCCVwqQ@mail.gmail.com/,
> and brian's notes about [CPU multi-]threading elsewhere in this email
> thread we are in). And there are other benefits from using Rust that
> we believe would benefit our users. Thus, it's not just a question of
> responsibility to our users, because such a responsibility pulls us in
> different directions regarding usage of Rust. So we need to figure
> out how to weigh the needs of our different users. For many of us,
> and forgive the geeky comparison, we'll probably weigh those needs
> with something more akin to an L2 norm (most good for the most users)
> rather than an L-infinity norm (maximal difference in usability for a
> single user), which probably isn't to your liking.
>
:)
> Anyway, there's been lots of discussion already. We can certainly
> still discuss more about exactly how to announce, when to adopt Rust,
> whether we'll support an existing C-only version of git for a longer
> period of time than normal, and even whether to continue to delay
> adopting Rust for a little longer. But my personal guess is that
> attempting to stop adoption of Rust is unlikely to win at this point.
I wouldn't characterise my position as attempting to flat-out stop
adoption of Rust (see beginning of this email).
>
>> > Hopefully the platforms that we currently support but won't after this
>> > patch series have niche enough workloads that they do not need the
>> > absolute latest-and-greatest Git release at all times.
>>
>> I mention this in my other email, but it's not just about ancient
>> platforms. It's also about new ones, or ones where Rust supports them
>> poorly despite them being relevant.
>
> This feels like you're trying to push the decision for a given
> platform to be a dichotomy between latest-and-greatest-Git or
> no-version-of-Git-at-all, despite the fact that Taylor suggested an
> alternative and you even quoted him. Can you comment on that
> alternative? Why would using the last C-only version of Git[1] until
> gccrs bridges the gap be a problem for these platforms?
What I was saying there was: it matters for platforms where they may not
have a git at all (because they're new, and we have a bit of a
bootstrapping problem), not just old ones where they're stuck on an old git.
Part of what I had in mind here is that sticking on old versions even
temporarily isn't necessarily a great option, see the recent issues w/
backports done (https://lore.kernel.org/git/xmqqldov4rpt.fsf@gitster.g/,
and https://lore.kernel.org/git/20250708210529.1214574-1-tmz@pobox.com/).
---
As a final note: I am genuinely not trying to be a member of the peanut
gallery wishing to prevent git's progress if the project wants to adopt
Rust, just there's some real practical obstacles for us right now.
I hope it didn't come across that way, but "dichotomy" appearing a few
times in your reply made me fear it did.
>
> Thanks,
> Elijah
thanks,
sam
>
> [1] Well, C-only other than optional Rust components like
> contrib/libgit-rs and contrib/libgit-sys that have already been
> released.
next prev parent reply other threads:[~2025-07-22 21:55 UTC|newest]
Thread overview: 206+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-17 20:32 [PATCH 0/7] RFC: Accelerate xdiff and begin its rustification Ezekiel Newren via GitGitGadget
2025-07-17 20:32 ` [PATCH 1/7] xdiff: introduce rust Ezekiel Newren via GitGitGadget
2025-07-17 21:30 ` brian m. carlson
2025-07-17 21:54 ` Junio C Hamano
2025-07-17 22:39 ` Taylor Blau
2025-07-18 23:15 ` Ezekiel Newren
2025-07-23 21:57 ` brian m. carlson
2025-07-23 22:26 ` Junio C Hamano
2025-07-28 19:11 ` Ezekiel Newren
2025-07-31 22:37 ` brian m. carlson
2025-07-22 22:02 ` Mike Hommey
2025-07-22 23:52 ` brian m. carlson
2025-07-17 22:38 ` Taylor Blau
2025-07-17 20:32 ` [PATCH 2/7] xdiff/xprepare: remove superfluous forward declarations Ezekiel Newren via GitGitGadget
2025-07-17 22:41 ` Taylor Blau
2025-07-17 20:32 ` [PATCH 3/7] xdiff: delete unnecessary fields from xrecord_t and xdfile_t Ezekiel Newren via GitGitGadget
2025-07-17 20:32 ` [PATCH 4/7] xdiff: make fields of xrecord_t Rust friendly Ezekiel Newren via GitGitGadget
2025-07-17 22:46 ` Taylor Blau
2025-07-17 23:13 ` brian m. carlson
2025-07-17 23:37 ` Elijah Newren
2025-07-18 0:23 ` Taylor Blau
2025-07-18 0:21 ` Taylor Blau
2025-07-18 13:35 ` Phillip Wood
2025-07-28 19:34 ` Ezekiel Newren
2025-07-28 19:52 ` Phillip Wood
2025-07-28 20:14 ` Ezekiel Newren
2025-07-31 14:20 ` Phillip Wood
2025-07-31 20:58 ` Ezekiel Newren
2025-08-01 9:14 ` Phillip Wood
2025-07-28 20:53 ` Junio C Hamano
2025-07-28 20:00 ` Collin Funk
2025-07-20 1:39 ` Johannes Schindelin
2025-07-17 20:32 ` [PATCH 5/7] xdiff: separate parsing lines from hashing them Ezekiel Newren via GitGitGadget
2025-07-17 22:59 ` Taylor Blau
2025-07-18 13:34 ` Phillip Wood
2025-07-17 20:32 ` [PATCH 6/7] xdiff: conditionally use Rust's implementation of xxhash Ezekiel Newren via GitGitGadget
2025-07-17 23:29 ` Taylor Blau
2025-07-18 19:00 ` Junio C Hamano
2025-07-31 21:13 ` Ezekiel Newren
2025-08-02 7:53 ` Matthias Aßhauer
2025-07-19 21:53 ` Johannes Schindelin
2025-07-20 10:14 ` Phillip Wood
2025-09-23 9:57 ` gitoxide-compatible licensing of Git's Rust code, was " Johannes Schindelin
2025-09-23 17:48 ` Jeff King
2025-09-24 13:48 ` Phillip Wood
2025-09-25 2:25 ` Jeff King
2025-09-25 5:42 ` Patrick Steinhardt
2025-09-26 10:06 ` Phillip Wood
2025-10-03 3:18 ` Jeff King
2025-10-03 9:51 ` Phillip Wood
2025-10-07 9:11 ` Patrick Steinhardt
2025-11-17 13:37 ` Johannes Schindelin
2025-10-05 5:32 ` Yee Cheng Chin
2025-07-17 20:32 ` [PATCH 7/7] github_workflows: install rust Ezekiel Newren via GitGitGadget
2025-07-17 21:23 ` brian m. carlson
2025-07-18 23:01 ` Ezekiel Newren
2025-07-25 23:56 ` Ben Knoble
2025-07-19 21:54 ` Johannes Schindelin
2025-07-17 21:51 ` [PATCH 0/7] RFC: Accelerate xdiff and begin its rustification brian m. carlson
2025-07-17 22:25 ` Taylor Blau
2025-07-18 0:29 ` brian m. carlson
2025-07-22 12:21 ` Patrick Steinhardt
2025-07-22 15:56 ` Junio C Hamano
2025-07-22 16:03 ` Sam James
2025-07-22 21:37 ` Elijah Newren
2025-07-22 21:55 ` Sam James [this message]
2025-07-22 22:08 ` Collin Funk
2025-07-18 9:23 ` Christian Brabandt
2025-07-18 16:26 ` Junio C Hamano
2025-07-19 0:32 ` Elijah Newren
2025-07-18 13:34 ` Phillip Wood
2025-07-18 21:25 ` Eli Schwartz
2025-07-19 0:48 ` Haelwenn (lanodan) Monnier
2025-07-22 12:21 ` Patrick Steinhardt
2025-07-22 14:24 ` Patrick Steinhardt
2025-07-22 15:14 ` Eli Schwartz
2025-07-22 15:56 ` Sam James
2025-07-23 4:32 ` Patrick Steinhardt
2025-07-24 9:01 ` Pierre-Emmanuel Patry
2025-07-24 10:00 ` Patrick Steinhardt
2025-07-28 9:06 ` Pierre-Emmanuel Patry
2025-07-18 14:38 ` Junio C Hamano
2025-07-18 21:56 ` Ezekiel Newren
2025-07-21 10:14 ` Phillip Wood
2025-07-21 18:33 ` Junio C Hamano
2025-07-19 21:53 ` Johannes Schindelin
2025-07-20 8:45 ` Matthias Aßhauer
2025-08-15 1:22 ` [PATCH v2 00/17] " Ezekiel Newren via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 01/17] doc: add a policy for using Rust brian m. carlson via GitGitGadget
2025-08-15 17:03 ` Matthias Aßhauer
2025-08-15 21:31 ` Junio C Hamano
2025-08-16 8:06 ` Matthias Aßhauer
2025-08-19 2:06 ` Ezekiel Newren
2025-08-15 1:22 ` [PATCH v2 02/17] xdiff: introduce rust Ezekiel Newren via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 03/17] xdiff/xprepare: remove superfluous forward declarations Ezekiel Newren via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 04/17] xdiff: delete unnecessary fields from xrecord_t and xdfile_t Ezekiel Newren via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 05/17] xdiff: make fields of xrecord_t Rust friendly Ezekiel Newren via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 06/17] xdiff: separate parsing lines from hashing them Ezekiel Newren via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 07/17] xdiff: conditionally use Rust's implementation of xxhash Ezekiel Newren via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 08/17] github workflows: install rust Ezekiel Newren via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 09/17] Do support Windows again after requiring Rust Johannes Schindelin via GitGitGadget
2025-08-15 17:12 ` Matthias Aßhauer
2025-08-15 21:48 ` Junio C Hamano
2025-08-15 22:11 ` Johannes Schindelin
2025-08-15 23:37 ` Junio C Hamano
2025-08-15 23:37 ` Junio C Hamano
2025-08-16 8:53 ` Matthias Aßhauer
2025-08-17 15:57 ` Junio C Hamano
2025-08-19 2:22 ` Ezekiel Newren
2025-08-15 1:22 ` [PATCH v2 10/17] win+Meson: allow for xdiff to be compiled with MSVC Johannes Schindelin via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 11/17] win+Meson: do allow linking with the Rust-built xdiff Johannes Schindelin via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 12/17] github workflows: define rust versions and targets in the same place Ezekiel Newren via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 13/17] github workflows: upload Cargo.lock Ezekiel Newren via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 14/17] xdiff: implement a white space iterator in Rust Ezekiel Newren via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 15/17] xdiff: create line_hash() and line_equal() Ezekiel Newren via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 16/17] xdiff: optimize case where --ignore-cr-at-eol is the only whitespace flag Ezekiel Newren via GitGitGadget
2025-08-15 1:22 ` [PATCH v2 17/17] xdiff: use rust's version of whitespace processing Ezekiel Newren via GitGitGadget
2025-08-15 15:07 ` [-SPAM-] [PATCH v2 00/17] RFC: Accelerate xdiff and begin its rustification Ramsay Jones
2025-08-19 2:00 ` Elijah Newren
2025-08-24 16:52 ` Patrick Steinhardt
2025-08-18 22:31 ` Junio C Hamano
2025-08-18 23:52 ` Ben Knoble
2025-08-19 1:52 ` Elijah Newren
2025-08-19 9:47 ` Junio C Hamano
2025-08-23 3:55 ` [PATCH v3 00/15] RFC: Cleanup " Ezekiel Newren via GitGitGadget
2025-08-23 3:55 ` [PATCH v3 01/15] doc: add a policy for using Rust brian m. carlson via GitGitGadget
2025-08-23 3:55 ` [PATCH v3 02/15] xdiff: introduce rust Ezekiel Newren via GitGitGadget
2025-08-23 13:43 ` rsbecker
2025-08-23 14:26 ` Kristoffer Haugsbakk
2025-08-23 15:06 ` rsbecker
2025-08-23 18:30 ` Elijah Newren
2025-08-23 19:24 ` brian m. carlson
2025-08-23 20:04 ` rsbecker
2025-08-23 20:36 ` Sam James
2025-08-23 21:17 ` Haelwenn (lanodan) Monnier
2025-08-27 1:57 ` Taylor Blau
2025-08-27 14:39 ` rsbecker
2025-08-27 17:06 ` Junio C Hamano
2025-08-27 17:15 ` rsbecker
2025-08-27 20:12 ` Taylor Blau
2025-08-27 20:22 ` Junio C Hamano
2025-09-02 11:16 ` Patrick Steinhardt
2025-09-02 11:30 ` Sam James
2025-09-02 17:27 ` brian m. carlson
2025-09-02 18:47 ` Sam James
2025-09-03 18:22 ` Collin Funk
2025-09-03 5:40 ` Patrick Steinhardt
2025-09-03 16:22 ` Ramsay Jones
2025-09-03 22:10 ` Junio C Hamano
2025-09-03 22:48 ` Josh Steadmon
2025-09-04 11:10 ` Patrick Steinhardt
2025-09-04 15:45 ` Junio C Hamano
2025-09-05 8:23 ` Patrick Steinhardt
2025-09-04 0:57 ` brian m. carlson
2025-09-04 11:39 ` Patrick Steinhardt
2025-09-04 13:53 ` Sam James
2025-09-05 3:55 ` Elijah Newren
2025-09-04 23:17 ` Ezekiel Newren
2025-09-05 3:54 ` Elijah Newren
2025-09-05 6:50 ` Patrick Steinhardt
2025-09-07 4:10 ` Elijah Newren
2025-09-07 16:09 ` rsbecker
2025-09-08 10:12 ` Phillip Wood
2025-09-08 15:32 ` rsbecker
2025-09-08 15:10 ` Ezekiel Newren
2025-09-08 15:41 ` rsbecker
2025-09-08 15:31 ` Elijah Newren
2025-09-08 15:36 ` rsbecker
2025-09-08 16:13 ` Elijah Newren
2025-09-08 17:01 ` rsbecker
2025-09-08 6:40 ` Patrick Steinhardt
2025-09-05 10:31 ` Phillip Wood
2025-09-05 11:32 ` Sam James
2025-09-05 13:14 ` Phillip Wood
2025-09-05 13:23 ` Patrick Steinhardt
2025-09-05 15:37 ` Junio C Hamano
2025-09-08 6:40 ` Patrick Steinhardt
2025-08-23 14:29 ` Ezekiel Newren
2025-08-23 3:55 ` [PATCH v3 03/15] github workflows: install rust Ezekiel Newren via GitGitGadget
2025-08-23 3:55 ` [PATCH v3 04/15] win+Meson: do allow linking with the Rust-built xdiff Johannes Schindelin via GitGitGadget
2025-08-23 3:55 ` [PATCH v3 05/15] github workflows: upload Cargo.lock Ezekiel Newren via GitGitGadget
2025-08-23 3:55 ` [PATCH v3 06/15] ivec: create a vector type that is interoperable between C and Rust Ezekiel Newren via GitGitGadget
2025-08-23 8:12 ` Kristoffer Haugsbakk
2025-08-23 9:29 ` Ezekiel Newren
2025-08-23 16:14 ` Junio C Hamano
2025-08-23 16:37 ` Ezekiel Newren
2025-08-23 18:05 ` Junio C Hamano
2025-08-23 20:29 ` Ezekiel Newren
2025-08-25 19:16 ` Elijah Newren
2025-08-26 5:40 ` Junio C Hamano
2025-08-24 13:31 ` Ben Knoble
2025-08-25 20:40 ` Ezekiel Newren
2025-08-26 13:30 ` D. Ben Knoble
2025-08-26 18:47 ` Ezekiel Newren
2025-08-26 22:01 ` brian m. carlson
2025-08-23 3:55 ` [PATCH v3 07/15] xdiff/xprepare: remove superfluous forward declarations Ezekiel Newren via GitGitGadget
2025-08-23 3:55 ` [PATCH v3 08/15] xdiff: delete unnecessary fields from xrecord_t and xdfile_t Ezekiel Newren via GitGitGadget
2025-08-23 3:55 ` [PATCH v3 09/15] xdiff: make fields of xrecord_t Rust friendly Ezekiel Newren via GitGitGadget
2025-08-23 3:55 ` [PATCH v3 10/15] xdiff: use one definition for freeing xdfile_t Ezekiel Newren via GitGitGadget
2025-08-23 3:55 ` [PATCH v3 11/15] xdiff: replace chastore with an ivec in xdfile_t Ezekiel Newren via GitGitGadget
2025-08-23 3:55 ` [PATCH v3 12/15] xdiff: delete nrec field from xdfile_t Ezekiel Newren via GitGitGadget
2025-08-23 3:55 ` [PATCH v3 13/15] xdiff: delete recs " Ezekiel Newren via GitGitGadget
2025-08-23 3:55 ` [PATCH v3 14/15] xdiff: make xdfile_t more rust friendly Ezekiel Newren via GitGitGadget
2025-08-23 3:55 ` [PATCH v3 15/15] xdiff: implement xdl_trim_ends() in Rust Ezekiel Newren via GitGitGadget
-- strict thread matches above, loose matches on Subject: below --
2025-07-25 23:53 [PATCH 0/7] RFC: Accelerate xdiff and begin its rustification Ben Knoble
2025-07-25 23:53 Ben Knoble
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o6tbevql.fsf@gentoo.org \
--to=sam@gentoo$(echo .)org \
--cc=eschwartz@gentoo$(echo .)org \
--cc=ezekielnewren@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitgitgadget@gmail$(echo .)com \
--cc=me@ttaylorr$(echo .)com \
--cc=newren@gmail$(echo .)com \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox