Currently, the API reference section for GitPython on readthedocs.io just shows the headings:

This is happening for version 3.1.15, "stable", and "latest":
3.1.14 looks fine, however:

https://gitpython.readthedocs.io/en/3.1.14/reference.html
it seems like something about the autodocs changed between 3.1.14 and 3.1.15
It becomes clear that the addition of types broke the API doc rendering - 3.1.15 (YANKED) added types as major feature.
Thus far there is no new release, but more and more types are added right now and there is no turning back from it.

What they call latest seems pretty old judging by the build logs. However, the most recent one is three weeks old and I add it here in case it contains useful information. Maybe you could have a look, too.
https://readthedocs.org/api/v2/build/13566171.txt
There are lot of failed imports of gitdb, but it's merely a warning.
Here is the log for 3.1.14, the latest working one.
https://readthedocs.org/api/v2/build/13122709.txt
There we don't have the warnings related to gitdb. Maybe that's a lead, and maybe that tells us it's not related to types at all but to something related to how gitdb is handled.
Maybe there would be a way to git-bisect while running autodoc to figure out which commit exactly is causing this, when studying the changes between 3.1.14 and 3.1.15 I saw nothing explicitly related to gitdb.
Any help is appreciated.
Hi,
I've been looking into this, and I don't think it has anything to do with typing. I've checked every PR and all the commits in the 1 typing-PR between v3.1.14 and v3.1.15.
However, I eventually noticed that Gitdb docs are also broken since v4.0.6. That was released 25th March, in between Gitpython v3.1.14 and v3.1.15, so changes there were pulled across to here, as a submodule or from pypi. I've not PRed any typings to Gitdb yet, so that cant be the cause.
I've not used autodocs before, so I can't check if pinning to older dependancies (before changing the signing key? earlier smmap?) fixes it. When the docs are built, where do the files go? I tried removing the /build cleanup step on my fork, but still not getting any files I can check.
Another thing i noticed: pythonpackage.yml used to import gibdb and ssmap as submodules. This now fails to pass tests unless gitdb is also pip installed (fails with "fatal: exec 'rev-list': cd to 'gitdb/ext/smmap' failed: No such file or directory" and "ModuleNotFoundError (No module named 'gitdb')".
(But also fails if the submodule import removed instead!)
I've been looking into this, and I don't think it has anything to do with typing. I've checked every PR and all the commits in the 1 typing-PR between v3.1.14 and v3.1.15.
Thanks a lot, me concluding that this happened due to typing was an unvalidated assumption, my apologies.
When the docs are built, where do the files go?
From the doc directory make html should build docs into the doc/html subdirectory if sphinx-build is available in the PATH.
Another thing i noticed: pythonpackage.yml used to import gibdb and ssmap as submodules. This now fails to pass tests unless gitdb is also pip installed (fails with "fatal: exec 'rev-list': cd to 'gitdb/ext/smmap' failed: No such file or directory" and "ModuleNotFoundError (No module named 'gitdb')".
That's interesting, CI seems to be green. However, that in conjunction with some changes to GitDb might actually help to solve this, and locally reproducing the docs build is certainly the way to go.
Yep, the CI works because gitdb was added to test-requirements.txt in May (in order to get CI to pass adter ModuleNotFoundError apeared).
So in pythonpackage.yml gitdb/smmap is getting imported from test-requirements.txt afterbeing import as submodules and masking any potential problems from submodules.
Doesn't identify the issue, but something about gitdb submodule changed then, coincident with the docs breaking.

I think it's fixed now. Please see the linked issue for details.