correctly handle uname-cmd that doesn't point to an executable file

[gcmarx]

I also ran into the issue from #1979. My proposed solution is that GitPython should only try to run uname_cmd if it points to an executable file. I also wrote a short test class for the is_cygwin_git function. I don't have a machine with Cygwin, so I can't test that it actually does work, but I trust the Python docs when they say that on Cygwin, sys.platform will be cygwin.

[gcmarx]

honestly, after having written this code, I'm not sure why we're not just delegating is_cygwin_git to sys.platform == "cygwin".

[gcmarx]

see #2027 for a different implementation of the same basic logic

[Copilot]

Pull Request Overview

This PR fixes the handling of cases where the uname command (used to detect Cygwin Git) is not an executable file and adds unit tests for verifying the behavior of is_cygwin_git. It also includes an update to the AUTHORS file to add a new contributor.

• Updated test_util.py to add tests for is_cygwin_git.
• Revised git/util.py to check if uname_cmd is an executable file before invoking it.
• Updated AUTHORS list.

Reviewed Changes

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

File	Description
test/test_util.py	Added unit tests for is_cygwin_git functionality
git/util.py	Updated uname command executable check and caching logic
AUTHORS	Added new contributor

[Byron]

Thanks for contributing a fix!

Indeed, I don't know why we are in the current place, but @EliahKagan probably has more information and I hope he can chime in.

Besides that, my apologies, I did click the "copilot" review button out of curiosity, please feel free to completely ignore it.

[gcmarx]

...incidentally, is there a way for me to run the test pipeline locally without pushing my changes up first?

[EliahKagan]

As argued in #2027 (comment), I think we should actually merge cffa264 -- that is, this PR as it was before the change to using strings -- before proceeding with further changes. I think that could be done at any time. I suggest rewinding this PR to that point (you can preserve the extra commits on their own separate branch of course).

There are some minor refinements that could be included with that, but they can just as easily be done afterwards (for example, I can make a small PR later that includes them), so they're not blocking. I've included review comments below showing them as suggested-change diffs.

In addition to the reasons given in #2027 (comment) for starting that way, I also think it matches the scope you may have intended for this PR originally, based on the PR title.

This is not to say that the attempt to examine the contents of the git executable file to discern if it is a Cygwin build should be discarded entirely -- only that I recommend integrating the working changes from before that, and then continuing with that subsequently. To that end, I've also included some review comments pertaining to those subsequent commits. To avoid confusion, I have refrained from including any suggested-change diffs in those.

---

...incidentally, is there a way for me to run the test pipeline locally without pushing my changes up first?

Yes, certainly. There are instructions in the readme, there is tox.ini if you want to use the tox runner, and the commands in the CI workflows in .github/workflows can sometimes be useful. I'm also happy to help with any questions about setting that up or problems that arise with it (and please feel free to ping me about it). There is also software to attempt to run GitHub Actions workflows locally, such as act, though I have not tried that on this repository and I don't know how well it would work.

However, in order to run the Cygwin tests on your local machine--using any of those techniques or others--I think you would need to have a Windows system (or other system capable of running Windows programs) with Cygwin installed on it.

[EliahKagan]

Thanks!