Elijah Newren <newren@xxxxxxxxx> writes: > What if Ezekiel rebased his series on am/xdiff-hash-tweak, and then > instead of further modifying the hashing in the first series, he: > - introduced brian's patch with the platform support > - setup the CI builds to test building with Rust (including Johannes' patches) > - started working on transitioning xdfile_t data structure to be FFI friendly Yup, that matches my understanding of what our first Rust topic would want to achieve, i.e. get the framework right. > One issue here is that it probably wouldn't be too long before we'd > want to rip out the xdlclassifier struct (mostly a glorified > hashtable), which is kind of tied up in a knot with the hashing and > line equality, so it would probably only be a few more series down the > road before we'd want to start tweaking the code in > am/xdiff-hash-tweak to make use of the new data structures. I understand that at this point we do not expect to import any (security or otherwise) fixes to xdiff code from "upstream", as we are practically the upstream for other folks? For our consumption, that would allow us to take a quite different stance from our historical attitude, which was to keep the modification to the minimum, and apply whatever clean-ups and optimizations only to suit our needs. So what you outline does make certain sense to me. I am however not sure if we owe anything to our downstream projects, though (e.g., I understand that libgit2 extracted xdiff part from our source, so if we have serious security fixes in ours, they would want to be able to import them?). Thanks.
