The version_info attribute of Git instances drops non-numeric fields, even if they appear before a field that is kept:

If a non-numeric field is followed by a numeric field, the effect is to make it look like the field that was actually non-numeric has the value of the subsequent field:

(.venv) ek@Glub:~/repos-wsl/GitPython (main $=)$ cat >fake-git <<'EOF'
> #!/bin/sh
> printf 'git version 1.2a.3 (totally fake)\n'
> EOF
(.venv) ek@Glub:~/repos-wsl/GitPython (main $%=)$ chmod +x fake-git
(.venv) ek@Glub:~/repos-wsl/GitPython (main $%=)$ python
Python 3.12.1 (main, Dec 10 2023, 15:07:36) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import git
>>> git.refresh('fake-git')
>>> git.Git().version_info
(1, 3)

(As shown, partially numeric fields that do not wholly parse to a number are non-numeric for this purpose.)

I think this should either be changed to stop before the first non-numeric field, or kept as it is but with this behavior documented explicitly to reduce confusion. In the latter case, the rationale should be given. The rationale may just be backward compatibility, though I am not sure if that is a sufficient reason to keep this behavior, since it seems unexpected in the cases where it makes a difference. There may be other alternatives that I haven't thought of.

I think this is a minor issue, since such versions may be rare or nonexistent. git version numbers that have a non-numeric field followed by a numeric field are common, such as 2.43.0.windows.1 on Windows. However, GitPython only looks at the first four fields, so the trailing 1 in 2.43.0.windows.1 is not wrongly presented as the field that follows the 0.

From the comments, it looks like this situation was specifically envisioned, suggesting that the exact current behavior may be intended:

However, it seems more likely to me that it was done this way to preserve earlier logic while fixing a specific bug. The if n.isdigit() filter was added in 6a61110 (#195).

Full current code for context:

This may make sense to fix at the same time as #1829 and/or #1830, I'm not sure.