Re: [PATCH 12/14] rust: add a new binary loose object map format

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 29, 2025, 17:03 UTC
Message-ID: <xmqqfrb1abd3.fsf@gitster.g>
In-Reply-To: <20251027004404.2152927-13-sandals@crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> Our current loose object format has a few problems.  First, it is not
> efficient: the list of object IDs is not sorted and even if it were,
> there would not be an efficient way to look up objects in both
> algorithms.

I was confused by reading the above, mostly because "our current loose object format" meant to me the "<type> SP <length-in-decimal> NUL <payload>" deflated with zlib, which has no list of object IDs.

As Patrick commented you are talking about something else? Mapping mechanism for object names between primary and compat hash algorithms?

Show 22 quoted lines

> +== Loose object mapping
> +
> +When the `compatObjectFormat` option is used, Git needs to store a mapping
> +between the repository's main algorithm and the compatibility algorithm. There
> +are two formats for this: the legacy mapping and the modern mapping.
> +
> +=== Legacy mapping
> +
> +The compatibility mapping is stored in a file called
> +`$GIT_DIR/objects/loose-object-idx`.  The format of this file looks like this:
> +
> +  # loose-object-idx
> +  (main-name SP compat-name LF)*
> +
> +`main-name` refers to hexadecimal object ID of the object in the main
> +repository format and `compat-name` refers to the same thing, but for the
> +compatibility format.
> +
> +This format is read if it exists but is not written.
> +
> +Note that carriage returns are not permitted in this file, regardless of the
> +host system or configuration.

Unless it is zero cost to keep supporting the reading side, perhaps we want to drop this mapping file format?