Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork939
correctly handleuname-cmd
that doesn't point to an executable file#2026
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation
…re trying to run it"This reverts commitde5e57c.
… it could both exist and have os.X_OK but not work
honestly, after having written this code, I'm not sure why we're not just delegating |
see#2027 for a different implementation of the same basic logic |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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 |
Uh oh!
There was an error while loading.Please reload this page.
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. |
...incidentally, is there a way for me to run the test pipeline locally without pushing my changes up first? |
EliahKagan left a comment• edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
As argued in#2027 (comment), I think we should actually mergecffa264 -- that is, this PR as it was before the change to usingstrings
-- 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 thegit
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 istox.ini
if you want to use thetox
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 asact
, 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.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Thanks! |
8576534
intogitpython-developers:mainUh oh!
There was an error while loading.Please reload this page.
I also ran into the issue from#1979. My proposed solution is that
GitPython
should only try to rununame_cmd
if it points to an executable file. I also wrote a short test class for theis_cygwin_git
function. I don't have a machine with Cygwin, so I can't test that it actually does work, but I trust thePython docs when they say that on Cygwin,sys.platform
will becygwin
.