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

[Jeff King <peff@peff.net>]

Reading Scott's blog post and accompanying HN comments the other day,
one upcoming usability headache stood out to me: first-time pushes to
newly created repositories.

If you create a bare repo on a forge like GitHub, it must be either sha1
or sha256. If the forge continues to create sha1 bare repos by default,
then all of the post-3.0 sha256 users will get this on first push:

  $ git push
  fatal: the receiving end does not support this repository's hash algorithm
  fatal: the remote end hung up unexpectedly

And then they have to go switch or recreate their remote repo. And if
the forge flips to sha256, then we have the opposite problem for pre-3.0
users (and even 3.0 users who are doing a first-push of existing sha1
repositories).

Savvy users will of course specify the object format they expect to use
when they create the server-side repo. But most users won't know or care
about this, and even if they do, it's an easy thing to forget about. So
I expect we'll see a lot of frustration here.

It would be nice if the empty repository could adapt to the object
format used by its first push. Then everything would just work from the
user's perspective, no matter what they push.

GitHub has long done something similar for the HEAD pointer; on first
push of a single branch it is pointed at that branch. There it was not
too hard to add custom code around Git that detected the situation and
set up the symref. But I don't think you can quite do the same thing for
the object format, because the push advertisement actually says "hey,
I'm a <hash> repo" in its capabilities. So the client says "oh, that
doesn't match me" and bails before actually pushing anything.

So what I'm suggesting instead is that the server be allowed to
advertise a limbo state: it has no object format yet. And then client
can recognize object-format=limbo, and send back "I'm a <sha1|sha256>
repo, so that's what I'm sending you" in its capabilities response.  And
then the server receives that and shifts its local object-format to
match.

There are some tricky bits on the server side (e.g., you'd want to flip
the value atomically so that if you get two simultaneous mismatched
pushes, one of them gets rejected). But I can't think of any reason that
it couldn't conceptually work, and I feel like it would save a lot of
headaches.

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.

-Peff