commit-graph overflow generation chicken and egg

I hadn't touched my git.git repository for a while, so I upgraded to the most recent version of Git (v2.36.1) and was met with this:

  $ git rev-list --all
  fatal: commit-graph requires overflow generation data but has none

Not very friendly, but OK, maybe my commit graph is out of date. Let's regenerate it:

  $ git gc
  fatal: commit-graph requires overflow generation data but has none
  fatal: failed to run repack

OK, we can't get far enough in the gc to rebuild the commit graph. Let's try doing it manually:

  $ git commit-graph write --reachable
  fatal: commit-graph requires overflow generation data but has none
  $ git commit-graph write
  fatal: commit-graph requires overflow generation data but has none

Yikes. Here's where it happens within the write process:

  $ GIT_PROGRESS_DELAY=0 git commit-graph write
  Finding commits for commit graph among packed objects: 100% (360229/360229), done.
  Loading known commits in commit graph: 100% (78366/78366), done.
  Expanding reachable commits in commit graph: 78366, done.
  Clearing commit marks in commit graph: 100% (78366/78366), done.
  Finding extra edges in commit graph: 100% (78366/78366), done.
  Computing commit graph topological levels: 100% (78366/78366), done.
  Computing commit graph generation numbers: 100% (78366/78366), done.
  fatal: commit-graph requires overflow generation data but has none

Now being the enterprising fellow that I am, I was able to get out of it like this:

  $ rm -f objects/info/commit-graph
  $ git gc

But I wonder if this is a foot-gun waiting for some other user. I'm not sure how I got into the broken state exactly. The repo was last touched in December using a version of Git running 'next'. It worked fine with versions of Git prior to 6dbf4b8172 (commit-graph: declare bankruptcy on GDAT chunks, 2022-03-02). It's entirely possible that the bad state was generated by a version of Git that wasn't ever released, and this isn't a problem that normal humans would ever run into. It does feel a bit unfriendly that neither gc nor commit-graph could unstick things, though. Especially because 6dbf4b8172 says:

  [...]a previous version of Git wrote possibly erroneous data in these
  chunks with the IDs "GDAT" and "GDOV". By changing the IDs, newer
  versions of Git will silently ignore those older chunks[...]

Presumably we _are_ ignoring those chunks, but some other part of the commit-graph file has a dependency on them (and of course we don't have the new GDA2/GDO2 chunks to read in their place). If that's true, then the solution may be a more graceful "we can't use this commit graph" error return rather than the "fatal:" message seen above.

I have a copy of the broken repo state if anybody would care to look at it.

-Peff