> Le 22 juil. 2025 à 08:25, Patrick Steinhardt <ps@xxxxxx> 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
