[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.
GCC-rs will probably fix this general issue.
--
Eli Schwartz
