Re: a "limbo" object-format state for empty repositories?

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Oct 3, 2026, 01:07 UTC
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.

Show 17 quoted lines

> 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