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. Patrick [1]: https://github.com/libgit2/xdiff
