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

From: Jeff King <peff@peff.net>
Date: Oct 3, 2026, 01:25 UTC
Message-ID: <20261003012512.GA1324483@coredump.intra.peff.net>
In-Reply-To: <asBVY1WniGUo6bQS@fruit.crustytoothpaste.net>

On Sat, Oct 03, 2026 at 01:07:48AM +0000, brian m. carlson wrote:

Show 10 quoted lines

> > 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.

Yeah, that is a problem. It breaks older clients (that are at least new enough to understand object-format=) worse than a mismatched format does. I was thinking we could solve that with a new capability, let's call it "magic-limbo" for a moment. Older versions would ignore it.

But then what do we put in the object-format= field? We have to put _something_ valid, as even if we put nothing that is an implicit choice of sha1.

So I think the best we can do is advertise magic-limbo, and then new limbo-aware clients can always do the right thing. Clients which are new enough to understand object-format but don't understand limbo will use the server's object-format unconditionally. So the choice there does still matter. But if we don't switch to sha256-by-default until magic-limbo is implemented, then anybody who has a local sha256 repo got there intentionally, and presumably knows enough to configure the server side to match. So the sensible protocol advertisement for a limbo repo is "magic-limbo" plus "object-format=sha1".

> 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.

Yeah, I thought about emitting multiple but it seems like that introduces other weird corner cases. I think we really need a new capability so that new versions and use it and old ones will ignore it.

Show 7 quoted lines

> 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).

Those parts seem outside of the scope of Git, or at least its protocol. But yeah, I'd expect a forge like GitHub to let you say "do not allow the creation of sha1 repos in this account/org", and the object-format selector for a new repo (at the forge UI) should be a tri-state: sha1, sha256, or limbo. How that translates into Git commands is TBD: whether via config, or more likely, that you have to select the limbo state explicitly with a command-line option to git-init.

-Peff