public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Ben Knoble <ben.knoble@gmail•com>
To: Patrick Steinhardt <ps@pks•im>
Cc: "Haelwenn (lanodan) Monnier" <contact@hacktivis•me>,
	Eli Schwartz <eschwartz@gentoo•org>,
	Phillip Wood <phillip.wood123@gmail•com>,
	Ezekiel Newren via GitGitGadget <gitgitgadget@gmail•com>,
	git@vger•kernel.org, Elijah Newren <newren@gmail•com>,
	Ezekiel Newren <ezekielnewren@gmail•com>,
	Edward Thomson <ethomson@edwardthomson•com>,
	"brian m. carlson" <sandals@crustytoothpaste•net>,
	Taylor Blau <me@ttaylorr•com>, Christian Brabandt <cb@256bit•org>
Subject: Re: [PATCH 0/7] RFC: Accelerate xdiff and begin its rustification
Date: Fri, 25 Jul 2025 19:53:31 -0400	[thread overview]
Message-ID: <35287949-FD3E-4A5B-BC8E-A2389A077133@gmail.com> (raw)


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

             reply	other threads:[~2025-07-25 23:53 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-25 23:53 Ben Knoble [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-07-25 23:53 [PATCH 0/7] RFC: Accelerate xdiff and begin its rustification Ben Knoble
2025-07-17 20:32 Ezekiel Newren via GitGitGadget
2025-07-17 21:51 ` brian m. carlson
2025-07-17 22:25   ` Taylor Blau
2025-07-18  0:29     ` brian m. carlson
2025-07-22 12:21       ` Patrick Steinhardt
2025-07-22 15:56         ` Junio C Hamano
2025-07-22 16:03     ` Sam James
2025-07-22 21:37       ` Elijah Newren
2025-07-22 21:55         ` Sam James
2025-07-22 22:08           ` Collin Funk
2025-07-18  9:23 ` Christian Brabandt
2025-07-18 16:26   ` Junio C Hamano
2025-07-19  0:32     ` Elijah Newren
2025-07-18 13:34 ` Phillip Wood
2025-07-18 21:25   ` Eli Schwartz
2025-07-19  0:48     ` Haelwenn (lanodan) Monnier
2025-07-22 12:21       ` Patrick Steinhardt
2025-07-22 14:24     ` Patrick Steinhardt
2025-07-22 15:14       ` Eli Schwartz
2025-07-22 15:56       ` Sam James
2025-07-23  4:32         ` Patrick Steinhardt
2025-07-24  9:01           ` Pierre-Emmanuel Patry
2025-07-24 10:00             ` Patrick Steinhardt
2025-07-28  9:06               ` Pierre-Emmanuel Patry
2025-07-18 14:38 ` Junio C Hamano
2025-07-18 21:56   ` Ezekiel Newren
2025-07-21 10:14   ` Phillip Wood
2025-07-21 18:33     ` Junio C Hamano
2025-07-19 21:53 ` Johannes Schindelin
2025-07-20  8:45   ` Matthias Aßhauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=35287949-FD3E-4A5B-BC8E-A2389A077133@gmail.com \
    --to=ben.knoble@gmail$(echo .)com \
    --cc=cb@256bit$(echo .)org \
    --cc=contact@hacktivis$(echo .)me \
    --cc=eschwartz@gentoo$(echo .)org \
    --cc=ethomson@edwardthomson$(echo .)com \
    --cc=ezekielnewren@gmail$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitgitgadget@gmail$(echo .)com \
    --cc=me@ttaylorr$(echo .)com \
    --cc=newren@gmail$(echo .)com \
    --cc=phillip.wood123@gmail$(echo .)com \
    --cc=ps@pks$(echo .)im \
    --cc=sandals@crustytoothpaste$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox