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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 3223 bytes --]

On 2025-09-08 at 06:44:08, Patrick Steinhardt wrote:
> > Setting that aside for a moment, the idea of Git 2.55 becoming 3.0
> > seems like a good idea to me, assuming that doesn't rush brian on the
> > sha1/sha256 interop (since I think that's probably the paramount
> > feature of 3.0).
> 
> Yeah, the interop is definitely an important factor and the last part
> that I think is still missing for Git 3.0 to become viable.

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.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]