Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

Merged
EliahKagan merged 16 commits intogitpython-developers:mainfromgcmarx:main
May 28, 2025

Conversation

gcmarx
Copy link
Contributor

I also ran into the issue from#1979. My proposed solution is thatGitPython 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.

@gcmarx
Copy link
ContributorAuthor

honestly, after having written this code, I'm not sure why we're not just delegatingis_cygwin_git tosys.platform == "cygwin".

eighthave reacted with thumbs up emoji

@gcmarx
Copy link
ContributorAuthor

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

Copy link

@CopilotCopilotAI left a 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.

FileDescription
test/test_util.pyAdded unit tests for is_cygwin_git functionality
git/util.pyUpdated uname command executable check and caching logic
AUTHORSAdded new contributor

@Byron
Copy link
Member

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
Copy link
ContributorAuthor

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

Copy link
Member

@EliahKaganEliahKagan left a comment
edited
Loading

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.

@gcmarxgcmarx marked this pull request as draftMay 28, 2025 15:13
@gcmarxgcmarx marked this pull request as ready for reviewMay 28, 2025 17:06
@EliahKagan
Copy link
Member

Thanks!

@EliahKaganEliahKagan merged commit8576534 intogitpython-developers:mainMay 28, 2025
25 checks passed
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@ByronByronByron left review comments

Copilot code reviewCopilotCopilot left review comments

@EliahKaganEliahKaganEliahKagan approved these changes

Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

3 participants
@gcmarx@Byron@EliahKagan

[8]ページ先頭

©2009-2025 Movatter.jp