As discussed in gitpython-developers#2005 and gitpython-developers#2011, we had not been doing this before.
Conditions have changed in two relevant ways:

- The free-threaded interpreter has been around longer and it sees
  more use.

- The macOS runners are very fast now.

The specific motivations for doing this now are:

- In view of the condition described in gitpython-developers#2109 and how the change
  there seems to have helped with it, there's some reason to think
  *patch* versions of Python sometimes affect GitPython in ways it
  makes possibly unfounded assumptions about the effect of garbage
  collection. This mainly affects Windows and it is not specific to
  free-threaded builds. However, in principle we could also see
  assumptions violated in tests we think always work on Unix-like
  operating systems, due to differences in how garbage collection
  works in free-threaded interpreters. Therefore, the assumption
  that this only needs to be tested occasionally is not as well
  founded I assumed when I suggested testing it only on GNU/Linux.

- We may add 3.14 jobs to CI soon, and it's useful to be able to
  see how both free-threaded interpreters work on CI, as well as to
  confirm for at least a short while that they are continuing to
  work as expected.

This macOS free-threaded interpreter CI jobs could be disabled once
more if necessary, or if they're found to make CI complete slower
in PRs by even a small amount so long as they don't seem to be
surfacing anything.

As discussed in gitpython-developers#2005 and gitpython-developers#2011, we had not been doing this before.
Conditions have changed in two relevant ways:

- The free-threaded interpreter has been around longer and it sees
  more use.

- The macOS runners are very fast now.

The specific motivations for doing this now are:

- In view of the condition described in gitpython-developers#2109 and how the change
  there seems to have helped with it, there's some reason to think
  *patch* versions of Python sometimes affect GitPython in ways it
  makes possibly unfounded assumptions about the effect of garbage
  collection. This mainly affects Windows and it is not specific to
  free-threaded builds. However, in principle we could also see
  assumptions violated in tests we think always work on Unix-like
  operating systems, due to differences in how garbage collection
  works in free-threaded interpreters. Therefore, the assumption
  that this only needs to be tested occasionally is not as well
  founded I assumed when I suggested testing it only on GNU/Linux.

- We may add 3.14 jobs to CI soon, and it's useful to be able to
  see how both free-threaded interpreters work on CI, as well as to
  confirm for at least a short while that they are continuing to
  work as expected.

This macOS free-threaded interpreter CI jobs could be disabled once
more if necessary, or if they're found to make CI complete slower
in PRs by even a small amount so long as they don't seem to be
surfacing anything.

As discussed in gitpython-developers#2005 and gitpython-developers#2011, we had not been doing this before.
Conditions have changed in two relevant ways:

- The free-threaded interpreter has been around longer and it sees
  more use.

- The macOS runners are very fast now.

The specific motivations for doing this now are:

- In view of the condition described in gitpython-developers#2109 and how the change
  there seems to have helped with it, there's some reason to think
  *patch* versions of Python sometimes affect GitPython in ways it
  makes possibly unfounded assumptions about the effect of garbage
  collection. This mainly affects Windows and it is not specific to
  free-threaded builds. However, in principle we could also see
  assumptions violated in tests we think always work on Unix-like
  operating systems, due to differences in how garbage collection
  works in free-threaded interpreters. Therefore, the assumption
  that this only needs to be tested occasionally is not as well
  founded I assumed when I suggested testing it only on GNU/Linux.

- We may add 3.14 jobs to CI soon, and it's useful to be able to
  see how both free-threaded interpreters work on CI, as well as to
  confirm for at least a short while that they are continuing to
  work as expected.

This macOS free-threaded interpreter CI jobs could be disabled once
more if necessary, or if they're found to make CI complete slower
in PRs by even a small amount so long as they don't seem to be
surfacing anything.