Thanks a lot!

Do you think that it would be possible to use git.compat.typing instead to avoid repeating the logic everywhere where typing is used? I don't know if re-exporting entire modules is possible.

I think you meant git.types instead of git.compat.typing? The latter doesn't exist...

I think this was a clumsy way of asking if there is a less redundant way of specifying the imports. In git.compat types are re-exported based on some logic, so code could rely on importing git.compat.typing alone without repeating any logic.

Ah, like this?

# git/compat.py:
if sys.version_info[:2] >= (3, 8):
 import typing
else:
 import typing_extensions as typing
# elsewhere:
from .compat import typing

Unfortunately that has the annoying side effect of not being able to do from git.compat.typing import Literal because git.compat.typing wouldn't be a package/module.

@Byron, something like this? Or do you mean entirely replacing from typing ... with from git.compat.typing ...?

Thank you very much for this contribution, this looks good to me, and I assume @muggenhor saw nothing that would prevent a merge either.

Thanks! We're removing Python 3.7 support real soon from Gentoo, and so we're going to be one step closer to eliminating typing-extensions as well ;-).

Thank you very much for this contribution, this looks good to me, and I assume @muggenhor saw nothing that would prevent a merge either.

Nope, didn't see any obstacles. It looks good!