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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 3963 bytes --]

On 2026-10-03 at 01:25:12, Jeff King wrote:
> 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.

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]