Since Python 3.13, CPython supports building free-threaded interpreters, i.e. builds that support running with no global interpreter lock and mostly using a combination of narrower locks and lock-free synchronization instead. I think we should test with this on CI, if feasible.

Often the reason to do so would be to find concurrency bugs that might be surfaced or exacerbated by running without a GIL. However, for GitPython, that is not my main motivation. Rather, GitPython has observable behavioral changes under some changes to the interpreter's garbage collector implementation. It seems like this sometimes happens even with modest changes to the garbage collector. For example, from #1767, referencing python/cpython#97922:

I expect that differences in GC details arising from the difference between a GIL and free-threaded builds may also have relevant effects. While the need to call gc.collect in the test suite is usually confined to Windows (to force objects' __del__ method to be called, to close files, so the files can be deleted), I think it's valuable to test this on other systems as well.

Actually, I think it may be reasonable to test free-threaded builds only on Linux-based systems, at least initially. (If problems on Windows arise, then it will become more important to test them on Windows to detect regressions.) This is because such builds are easier to set up on CI on such systems, and because if something breaks on free-threaded interpreters that was already, in practice, working very well before, then that should be known.

So I think that while #1990 was certainly a blocker for this, #1955 is not, and that this could therefore be contributed at any time. However, in my opinion, #1955 is still higher priority than this, as are the other portability maintenance issues #2003 and #2004. I don't know if and when I would get to those, and I hope others will be able to help out; in view of that, it could be a while until I get to this, so I'm opening an issue so it is not forgotten.

It may also make sense to wait until the setup-python action gains the ability to install free-threaded builds. Based on actions/setup-python#771, I think that's not available yet, though based on actions/python-versions#319 being merged earlier today, it may be coming soon. However, there are also alternative actions that can install a free-threaded build, and various other installation methods that use prebuilt binaries.