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

[Jeff King <peff@peff.net>]

On Sat, Oct 03, 2026 at 02:22:32PM +0000, brian m. carlson wrote:

> > 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".
> 
> We need to declare the other object format as well because we need to
> know that the server specifically supports SHA-256.  If we add a third
> hash algorithm, then maybe SHA-256 is unacceptable for that reason.  So
> maybe `alt-object-format=sha256`.  We do definitely need to be sure that
> multiple options are accepted, though.

Right, that makes sense. And the presence of alt-object-format would
replace the need for a separate magic-limbo at all.

> As I say below, we probably need to initialize with some hash algorithm
> at first, so we could also have `object-format=sha256` and
> `alt-object-format=sha1`.

Yeah, that makes sense.

> You hint at delaying SHA-256-by-default until this is implemented, but I
> don't think that's a good idea.

I wasn't proposing a delay. There's at least another whole release cycle
before 3.0, and this feature doesn't seem all that big. So it seemed
like something that could be implemented in that time-frame. I may or may
not work on it at some point; I just don't want to preclude anybody
(like Scott) who is interested and wanted to run with it.

> > 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.
> 
> I disagree that they're outside the scope of Git, but I do agree that we
> should add support for this either in the config or via a command-line
> option.  I think config would be better here because we also have to
> deal with the fact that someone might use commands other than push to
> write into the repository (on a forge, that might be the API) and we
> need to specify _some_ hash algorithm for that case.

Sorry, I just meant that policy decisions like "this account should not
be able to create sha1 repos" was outside of Git. We definitely need
some config flag to mark the limbo state (since it's set by "git init"
and ultimately respected by receive-pack and elsewhere). I would say
that any limbo-state feature should _not_ be on by default, but could be
a useful building block for forges that want to reduce friction. There'd
perhaps be some forge-specific work to do on top, too.

-Peff