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

From: Ben Knoble <[email-masked]>
Date: Fri, 25 Jul 2025 19:53:31 -0400

> Le 22 juil. 2025 à 08:25, Patrick Steinhardt <[email-masked]> a écrit :
> 
> On Sat, Jul 19, 2025 at 02:48:39AM +0200, Haelwenn (lanodan) Monnier wrote:
>> [2025-07-18 17:25:01-0400] Eli Schwartz:
>>> On 7/18/25 9:34 AM, Phillip Wood wrote:
>>>> Hi Ezekiel
>>>> Thanks for working on this
>>>> On 17/07/2025 21:32, Ezekiel Newren via GitGitGadget wrote:
>>>>> 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