From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 29 Oct 2025 17:03:52 GMT
Subject: Re: [PATCH 12/14] rust: add a new binary loose object map format
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?

> +== 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?