This applies two minor Cygwin-related clarifications, one of which is theoretically a bugfix though it affects conceptually non-public code that is currently not used in a way that could invoke the bug. Some specific details are in commit messages.

The second commit,988d97b, which fixesCOM to.COM in the fallback for thePATHEXT environment variable--whose omission is almost certainly a typo, going back to the function's introduction ine6e23ed (#533)--is theoretically a bugfix. But as noted there, this code is only called when the Python interpreter is a native Windows program, but the function it is a part of is only called when the Python interpreter isnot a native Windows program. (Also, it would be pretty unusual for thegit executable to have a.com extension.)

There are some further changes related to Cygwin detection that may make sense to make in the future, some of which might be best to make after adding relevant tests. The ones that are narrowly related to the change here are that:

• This value ofPATHEXT here is still unusual, because order matters and this lists.BAT before.COM and.EXE, and because it is missing.CMD, which is part of what a minimal value for it should typically contain. I am uncertain if this strange order is intentional.
• It may also make sense for the list to include.VBS,.JS,.WS, and.MSC for compatibility with the fallback behavior of the Windowscmd.exe shell whenPATHEXT is unset,which is whatshutil.which does. (I have verified the result of Eryk Sun's debugger check in WinDbg on recent builds of Windows 10 and Windows 11; they are the same.)
• py_where should really be removed and replaced either with a call toshutil.which, which did not exist at the timepy_where was introduced and would almost certainly have been used at that time if it had--or with other logic that works an altogether different way. Which should be done depends on the intent of the publicGit.is_cygwin_git class method, which is the only code in GitPython that uses theis_cygwin_git function ingit/util.py, for which thepy_where helper exists.

This PR doesn't try to cover any of that. It's really just applying some clarifications that didn't seem like they fit in any other PR that I would do soon.

Regarding the last point aboutGit.is_cygwin_git, if the goal is to detect Cygwin git even on native Windows systems, then the code it uses will have to be significantly revised. That is because currently it always returnsFalse on such systems. In addition, as noted in thepy_where docstring and elsewhere, shell and non-shell path search differ from each other on native Windows, such that neither the nonpublic ad-hocpy_where nor the public generalshutil.which will reliably tell us wheregit is. However, if a path search doesn't need to be done on native Windows, then it can be replaced withshutil.which unless some use has come to depend on (perhaps accidentally introduced) distinctive behavior ofpy_where.

I plan to open an issue about that larger matter, which I am unlikely to work on anytime soon, but that perhaps someone would be interested to take on. (If you know whatGit.is_cygwin_git's semantics are supposed to be, then I can make use of that information in the forthcoming issue, but I can still open it even if its intent is currently uncertain.)