From: "brian m. carlson" <sandals@crustytoothpaste•net>
To: Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org
Subject: Re: [PATCH] docs: note that extensions.compatobjectformat is experimental
Date: Mon, 25 Aug 2025 21:25:36 +0000 [thread overview]
Message-ID: <aKzU0IP8muy-j1TV@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <xmqqo6s3qpne.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 2995 bytes --]
On 2025-08-25 at 17:25:57, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste•net> writes:
>
> > The compatibility object format is only implemented for loose objects,
> > not packed objects, so anyone attempting to push or fetch data into a
> > repository with this option will likely not see it work as expected. In
> > addition, the underlying storage of loose object mapping is likely to
> > change because the current format is inefficient and does not handle
> > important mapping information such as that of submodules.
>
> It is "experimental" in the sense that a developer who is interested
> in making the feature work end-to-end for the first time can use the
> code behind the flag to prepare loose objects to prepare what is to
> be transferred; it sounds more like this one is "not working yet" ...
>
> > diff --git a/Documentation/config/extensions.adoc b/Documentation/config/extensions.adoc
> > index 9e2f321a6d..292e95ddae 100644
> > --- a/Documentation/config/extensions.adoc
> > +++ b/Documentation/config/extensions.adoc
> > @@ -14,6 +14,9 @@ compatObjectFormat::
> > compatObjectFormat. As well as being able to use oids encoded in
> > compatObjectFormat in addition to oids encoded with objectFormat to
> > locally specify objects.
> > ++
> > +Note that the functionality enabled by this option is experimental, incomplete,
> > +and subject to change.
>
> ... as the only end-user-perceivable purpose the compat format
> serves is to exchange data between two repositories that use
> different hash functions, no?
It works if you want to do `git rev-parse --output-object-format=sha1
<some-sha256-oid>` (or the reverse) and all of your objects entered the
repository as loose objects. Otherwise, it isn't very useful.
It definitely does not currently let you exchange data between two
repositories that use different hash functions unless you use my
in-progress branch.
The eventual goal is to let people do something like `git rev-parse
foobar^{sha1}` as well as interoperate with other repositories. Neither
of those are currently in place.
> The word "experimental" to me implies that it at least lets you
> complete a minimum end-user journey of the feature end-to-end.
I definitely don't think that's what it does. It has extremely limited
useful functionality, pretty much entirely confined to rev-parse.
> There are different degree of experimental in this project and we
> may want to do something about it, but in any case this is a welcome
> change in the right direction to steer those with mere curiosity
> away from hurting themselves.
>
> Note that the functionality hidden behind this extension is
> incomplete and the extension exists solely to allow us to
> continue developping it further.
>
> might give them a stronger discouragement?
I'll re-roll with something like that in v2.
--
brian m. carlson (they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2025-08-25 21:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-23 22:06 [PATCH] docs: note that extensions.compatobjectformat is experimental brian m. carlson
2025-08-25 17:25 ` Junio C Hamano
2025-08-25 21:25 ` brian m. carlson [this message]
2025-08-25 22:11 ` [PATCH v2] docs: note that extensions.compatobjectformat is incomplete brian m. carlson
2025-08-25 22:46 ` Junio C Hamano
2025-08-25 22:50 ` brian m. carlson
2025-08-25 23:00 ` Junio C Hamano
2025-08-25 22:50 ` [PATCH v3] " brian m. carlson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aKzU0IP8muy-j1TV@fruit.crustytoothpaste.net \
--to=sandals@crustytoothpaste$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox