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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 18, 2025, 16:26 UTC
Message-ID: <xmqqcy9x4g8n.fsf@gitster.g>
In-Reply-To: <aHoSjbV2nMZkBn5l@256bit.org>

Christian Brabandt <cb@256bit.org> writes:

Show 20 quoted lines

> On Do, 17 Jul 2025, Ezekiel Newren via GitGitGadget wrote:
>
>> This series accelerates xdiff by 5-19%.
>> 
>> It also introduces Rust as a hard dependency.
>> 
>> …and it doesn’t yet pass a couple of the github workflows; hints from
>> Windows experts, and opinions on ambiguous primitives would be appreciated
>> (see below).
>> 
>> This is just the beginning of many patches that I have to convert portions
>> of, maybe eventually all of, xdiff to Rust. While working on that
>> conversion, I found several ways to clarify the code, along with some
>> optimizations.
>
> Just a quick heads-up: We (as in Vim/Neovim) have been using gits xdiff 
> library for use in Vim and Neovim.
>
> Is the plan to get rid of xdiffs C source completely and replace it by a 
> Rust implementation?

As far as I know, there is no such plan that is widely agreed upon (yet).

The discussion starter thread you are looking at only introduces a new code path that uses a different line hash function written in Rust when whitespace munging search is not enabled, and everything else still is written in C, but since it is just a discussion starter so far.

I would personally have liked the effort to start with xmerge code, not xdiff machinery, for various reasons, but that may be just me ;-)