Pull Request Overview

This PR simplifies the detection of Cygwin Git by replacing the former multi-step logic with a concise check that relies on sys.platform.

• Removed deprecated functions and caching logic for Cygwin detection.
• Updated the Git command interface to directly use sys.platform and the Git executable's existence.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

This is preliminary and I'll try to say a little more in a forthcoming review of#2026, which I hope to do tomorrow.

I think we'll probably want to prefer the approach in#2026 over this, at least in the short term. There is a deliberate and long-standing (though not always perfectly applied) distinction throughout the code of GitPython between whether the platform is Cygwin (i.e. whether thepython interpreter running the code of GitPython is a Cygwin program) and whether thegit executable that GitPython calls is a Cygwin program.

This appears to be relevant to the treatment of absolute paths in some operations that involve cloning to an absolute path or adding a submodule. Most use ofis_cygwin_git is throughGit.is_cygwin, and searching forGit.is_cygwin reveals uses where it looks like this distinction can matter.

GitPython uses whatevergit executable it is configured to use via environment variables orrefresh or, if it is not configured to use a particulargit executable, whatever executable it finds in a path search. In either case, this executable need not be built for the same target as GitPython.

I admittedly would not recommend most such mismatches betweenpython andgit if they can be avoided. I also think we should be willing to run the risk of breaking things in what I believe to be the unusual case of using Cygwingit from outside Cygwin, if doing so is necessary in order to avoid or fix breakages when Cygwin is not used--especially for bugs that affect users on Unix-like operating systems that aren't related to Windows. This is one of the reasons I anticipate that the approach in#2026 is probably okay.

But distinguishing Cygwinpython using Cygwingit from Cygwinpython using Git for Windowsgit seems like it is at least partially working. It's also fairly easy to produce the situation of Cygwinpython using Git for Windowsgit. This can plausibly occur intentionally or by accident. Most Cygwin environments preserve WindowsPATH entries, allowing them to appear after Cygwin-specificbin directories. If GitPython is used in Cygwinpython, on a system where Cygwingit is not installed but Git for Windowsis installed, thenusually the non-Cygwingit will be found in thePATH, and GitPython will use it.