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

[Jeff King <peff@peff.net>]

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

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

> 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