Re: [PATCH 0/7] RFC: Accelerate xdiff and begin its rustification



Le 22 juil. 2025 à 08:25, Patrick Steinhardt [off-list ref] a écrit :

On Sat, Jul 19, 2025 at 02:48:39AM +0200, Haelwenn (lanodan) Monnier wrote:

quoted

[2025-07-18 17:25:01-0400] Eli Schwartz:

quoted

On 7/18/25 9:34 AM, Phillip Wood wrote:

quoted

Hi Ezekiel
Thanks for working on this
On 17/07/2025 21:32, Ezekiel Newren via GitGitGadget wrote:

quoted

So...
This obviously raises the question of whether we are ready to accept a
hard
dependency on Rust. Previous discussions on the mailing list and at Git
Merge 2024 have not answered that question. If not now, will we be
willing
to accept such a hard dependency later? And what route do we want to
take to
get there?

As far as git goes I think introducing a hard dependency on rust is
fine. It is widely supported, the only issue I'm aware of is the lack of
support on NonStop and I don't think it is reasonable for such a
minority platform to hold the rest of the project to ransom. There is a
question about the other users of the xdiff code though. libgit2 carries
a copy as do other projects like neovim. I've cc'd the libgit2
maintainer and posted a link to this thread in neovim github [1]

A hard dependency on rust for Gentoo amd64 would potentially require
building https://github.com/thepowersgang/mrustc followed by building 13
and counting versions of rustc in order to get to the latest version.
What is the minimum supported version in this series, by the way?
bin packages for rust do exist but not everyone wants to use non-distro
provided binaries, sometimes for auditability reasons.
For Gentoo HPPA, Alpha, m68k it will simply mean the removal (or end of
life and staying forever on 2.50, perhaps) of Git. There is no rust
compiler there.
Even s390 support for rust is limited to a precompiled version not
everyone is willing to use.

Also in other distro concerns, if it trickles down to libgit2,
extra care should be taken to avoid creating circular dependencies
due to cargo depending on libgit2 (via git2 crate).
For example with making sure it can reasonably be built via meson's
Rust support rather than through cargo.

I think it's unlikely that this eventually trickles down into libgit2.
The bundled versions of xdiff have already diverged for a long time, and
unfortunately libgit2 is mostly in maintenance mode nowadays. So I guess
that this change here just means that things will diverge even further
in the future, which is probably okay-ish. After all, the whole xdiff
library didn't really evolve in a fast pace over the last years.

That being said, there is an xdiff fork located at [1] that libgit2
maintains nowadays. So if the Rust dependency ever became a problem for
any of the downstream users I think we could simply redirect them to
that fork and make it the canonical upstream for C-only xdiff.

/cc Christian: if Vim absolutely demands a C-only xdiff, this may be a good place to get it long-term.

My preference would be for Vim to be able to get the benefits of Rusty xdiff or other speed up/safety benefits without extreme porting efforts (translating Rust patches back to C?), so perhaps a build mode that allowed me to supply my own xdiff lib would be ok as a start.

I’d be willing to lend a hand to help Vim support Rusty xdiff directly, too.

Patrick

[1]: https://github.com/libgit2/xdiff