From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Sat, 03 Oct 2026 01:07:48 GMT
Subject: Re: a "limbo" object-format state for empty repositories?
Message-ID: <asBVY1WniGUo6bQS@fruit.crustytoothpaste.net>
In-Reply-To: <20261002224400.GA834158@coredump.intra.peff.net>

On 2026-10-02 at 22:44:00, Jeff King wrote:
> It would be nice if the empty repository could adapt to the object
> format used by its first push. Then everything would just work from the
> user's perspective, no matter what they push.

I agree that would be nice.

> So what I'm suggesting instead is that the server be allowed to
> advertise a limbo state: it has no object format yet. And then client
> can recognize object-format=limbo, and send back "I'm a <sha1|sha256>
> repo, so that's what I'm sending you" in its capabilities response.  And
> then the server receives that and shifts its local object-format to
> match.
> 
> There are some tricky bits on the server side (e.g., you'd want to flip
> the value atomically so that if you get two simultaneous mismatched
> pushes, one of them gets rejected). But I can't think of any reason that
> it couldn't conceptually work, and I feel like it would save a lot of
> headaches.
> 
> But I also did just think of this idea, and haven't implemented anything
> (nor do I have immediate plans to). So it might be half-baked. But I
> thought I'd toss it out there and see if any body has thoughts, or feels
> strongly enough to try implementing it.

That is definitely something that could be added, but it's also
incompatible with every existing implementation.  Specifically using the
`object-format=limbo` approach means that no existing client from 2.29
on will work with the repository since `limbo` is not a valid hash
algorithm.

There is some support for multiple `object-format` directives, but I
don't know how well it works and I seem to remember that we had some
sort of crasher bug in the past.  That would be the best possible way to
advertise that, though, if older versions support it.

There are also going to be some policy decisions, for instance.  Some
organizations will not want to allow one algorithm or the other, so
Git will need some way to allow that behaviour to be expressed.  Or more
likely, Git needs some way to allow the fact that it's in versatile
mode to be expressed and that it's safe to rewrite the config on initial
write into the repository (which, to be clear, need not be a push; it
could also be a commit or add).

All that being said, it's not impossible, but it's also not easy.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA