Re: [PATCH RFC v2 0/7] Introduce Rust and announce that it will become mandatorty

On 2025-09-08 at 06:44:08, Patrick Steinhardt wrote:

I am definitely working on this at the moment and here's what I have working:

* Pack index v3
* Fetching and pushing for full (non-shallow, non-partial) clones
  without submodules

And I'm working on these:

* The new binary loose object map (I was debugging round-tripping this
  morning)
* Shallow fetches (which, due to the quarantine usage, need a binary
  loose object map rather than the `loose-object-idx` file, since the
  quarantine can't merge the two `loose-object-idx` files together)

And then I'll get to these:

* Shallow pushes
* Partial clone
* Garbage collecting and repacking binary loose object maps
* Submodule handling in the protocol

I will need to switch soon to writing my presentation for Git Merge, though, but afterwards I'm going to go back through the testsuite and see what else is failing. I expect partial and shallow clones to fix a lot of the remaining tests, but there are still going to be some problems to deal with.

Note that shallow and partial clones where the server supports only one algorithm won't work with interoperability, since those lack full data and the client side won't be able to map the objects between algorithms. There's also the problem that accepting submodule mappings introduces a security risk, since it's possible for the other side to send commit A in SHA-1 but commit B in SHA-256 and there's no real way to detect that unless you have the submodule on your side.

I may end up asking for some assistance in polishing and sending in what I have. Most of what I have is reasonably good quality[0] and should be bisectable, but I'm up to 81 patches before the Rust part of the code (which so far has 12 patches) and I'm worried I won't be able to both write it and get it sent in in nice-sized series before 3.0 is likely to happen.

Alternatively, we could maybe accept that interoperability is a nice-to-have for Git 3.0 and not an essential. It's not mentioned in the BreakingChanges document, so it's perhaps not a requirement. We could also have someone work on this as part of their job to get it handled more quickly[1].

Finally, I am currently interested in working on the interop code (but have no problem handing it off if that works better for the project), but I cannot guarantee that I will absolutely have time or inclination to continue.

[0] There are some patches marked WIP with a reason as to why they need work, but those are few and far between. [1] I think it's unlikely that this will be able to be me for reasons which I cannot share at the moment but hope to be able to later on, maybe at the Contributor Summit. I'll keep an eye out in case it becomes possible, though.