On 2025-10-29 at 09:08:05, Patrick Steinhardt wrote:
> I'm mostly asking all of these questions because this is our first Rust
> code in Git that is a bit more involved. So it's likely that this code
> will set precedent for how future code will look like, and ideally I'd
> like us to have code that is idiomatic Rust code.

In general, I'd like that, too, and that's a fair question.

> With the FFI code it's of course going to be a mixed bag, as we are
> somewhat bound by the C interfaces. But in the best case I'd imagine
> that we have low-level FFI primitives that bridge the gap between C and
> Rust, and then we build a higher-level interface on top of that which
> allows us to use it in an idiomatic fashion.

The reason I've made the decision to minimize conversions here is
because the object ID lookups are in a hot path in `index-pack` and
various protocol code.  If we clone the Linux repository (in SHA-1) and
want to convert it to SHA-256 as part of that clone, we may need to
convert every object and then deltify it to write the SHA-256 pack.
This is never going to really scream in terms of performance as you
might imagine, but it can be better or worse and I've tried to make it
a little better.

Similarly, if we have 500,000 refs on the remote[0], each of those
have/want pairs has to be potentially converted and we want people to
feel positively about our performance.

I will send a patch in a future series that will make this a little more
idiomatic on the Rust side as well.

> I guess all of this will require a lot of iteration anyway as we gain
> more familiarity with Rust in our codebase. And things don't have to be
> perfect on the first try *shrug*

Yeah, we'll come up with some standards and design guidance as things go
along.

[0] Some major users of Git do have this order of number of refs.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA