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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Oct 3, 2026, 14:22 UTC
Message-ID: <asEPp6Bg3xDpA4e1@fruit.crustytoothpaste.net>
In-Reply-To: <20261003012512.GA1324483@coredump.intra.peff.net>

On 2026-10-03 at 01:25:12, Jeff King wrote:

Show 18 quoted lines

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

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.

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

You hint at delaying SHA-256-by-default until this is implemented, but I don't think that's a good idea. I agree this would be a nice feature to implement, but I have no intention of implementing it and you said you didn't, either, so unless someone decides that they are going to implement it imminently, I don't think we should hold up Git 3.0 or the default algorithm change to then. As I mentioned, Git is really behind the times on moving away from SHA-1 and we need our users to choose sensible defaults as soon as possible. Git 3.0 moving to SHA-256 by default was announced in 2024 and given that I managed to write a functional interoperability implementation in that time, there has been plenty of time to say something and implement a solution.

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

The bug I mentioned was apparently not a crasher but an infinite loop: aa962fef27 ("v0 protocol: fix infinite loop when parsing multi-valued capabilities", 2023-04-14). However, it was fixed in 2.41, before SHA-256 became stable in 2.44. We could therefore implement it that way if we're willing to abandon versions of Git that only have experimental support for SHA-256.

Show 7 quoted lines

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

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA