To support #1659 here in GitPython, gitdb received #98, and the GitPython repository's submodule reference to gitdb was updated in #1704 (and #1705). Thus #1656 might be¹ fixed when developing against the cloned GitPython repository with its gitdb submodule.

With the intention of fixing #1656 in the far more common case of using GitPython via PyPI packages, GitPython 3.1.38 was released. But no new release of gitdb was ever made. Since the fix depends on changes to gitdb, it seems unlikely that 3.1.38 really fixes #1656.

I think it might be possible to make further refinements to __all__ and surrounding code, slightly enhancing #1659. However, since 3.1.38 was already released, it seems to me that such things can wait, and that it's reasonable to make a gitdb release (bumping the version in its setup.py and gitdb/__init__.py, or changing the current approach and bumping it in just one place), and to include a dependency bump requiring it the next GitPython release (which could be the same release that ships #1715, if the timing works out).

I'd be pleased to open pull requests to help with this issue, either following this plan or another one, if that would be helpful.

¹ I had originally said it was likely fixed when developing against the cloned GitPython. However, that is probably not the case. First, most type checkers probably wouldn't understand how that version is added to sys.path, and it is probably good design of them not to (since they are static checkers). Second, as documented in #1717, it turns out this is never actually happening.