Re: [PATCH 04/14] rust: add a ObjectID struct

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Oct 30, 2025, 00:32 UTC
Message-ID: <aQKyKU12229se0tU@fruit.crustytoothpaste.net>
In-Reply-To: <aQHZda5I0JPSRwv1@pks.im>

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.

Show 5 quoted lines

> 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