Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
4
contributors
Commits on Sep 12, 2023
Commits on Sep 25, 2023
-
This turns two tuple expression statements--each of an equality comparison and message--that were not being checked or otherwise used, and that were intended to be assertions, into assertions.
-
Merge pull request #1678 from EliahKagan/missing-asserts
Add missing assert keywords
-
Instrument workflows to investigate skipped tests
This makes jobs from both test workflows give more information relevant to examining which tests are skipped (and if any tests xfail, those too) in what environments: - Values of os.name and git.util.is_win. - The name of each test that runs, with its status. The latter doesn't increase the output length as much as might be expected, because due to the way the output is handled, the pytest-sugar pretty output format without -v looked like: test/test_actor.py ✓ 0% test/test_actor.py ✓✓ 0% ▏ test/test_actor.py ✓✓✓ 1% ▏ test/test_actor.py ✓✓✓✓ 1% ▏ When instead it was intended to fit on a single line. Still, the current output with -v has extra newlines, increasing length and worsening readability, so it should be improved on if possible.
-
Show version and platform info in one place
Instead of splitting it in into two places where at least one of the places is highly likely to be missed, this puts it together just before the first steps that makes nontrivial use of the installed packages. Grouping it together, it can't really be shown earlier, because one of the pieces of information is obtained using the git module (to examine that behavior of the code). This also presents the information more clearly. "set -x" makes this easy, so the commands are rewritten to take advantage of it.
-
-
Keep sugar for local use, but use instafail on CI
There are two benefits of the pytest-sugar plugin: 1. Pretty output. 2. Show details on each failure immediately instead of at the end. The first benefit is effectively local-only, because extra newlines are appearing when it runs on CI, both with and without -v. The second benefit applies both locally and on CI. So this adds the pytest-instafail plugin and uses it on CI to get the second benefit. It is not set up to run automatically, and pytest-sugar still is (though no longer forced), so local testing retains no benefit and we don't have a clash. The name "instafail" refers only to instantly *seeing* failures: it does not cause the pytest runner to stop earlier than otherwise.
-
Pass -v twice to see full skip reasons
+ Reorder pytest arguments so both workflows are consistent.
-
Force pytest color output on CI
While pytest-sugar output gets mangled with extra newlines on CI, colorized output seems to work fine and improves readability.
-
Fix test_blocking_lock_file for cygwin
This permits the longer delay in test_blocking_lock_file--which was already allowed for native Windows--on Cygwin, where it is also needed. That lets the xfail mark for Cygwin be removed. This also updates the comments to avoid implying that the need for the delay is AppVeyor-specific (it seems needed on CI and locally).
-
Run cygpath tests on Cygwin, not native Windows
They were not running on Cygwin, because git.util.is_win is False on Cygwin. They were running on native Windows, with a number of them always failing; these failures had sometimes been obscured by the --maxfail=10 that had formerly been used (from pyproject.toml). Many of them (not all the same ones) fail on Cygwin, and it might be valuable for cygpath to work on other platforms, especially native Windows. But I think it still makes sense to limit the tests to Cygwin at this time, because all the uses of cygpath in the project are in code that only runs after a check that the platform is Cygwin. Part of that check, as it is implemented, explicitly excludes native Windows (is_win must be false).
-
Two of the groups of cygpath tests in test_util.py generate tests that fail on Cygwin. There is no easy way to still run, but xfail, just the specific tests that fail, because the groups of tests are generated with `@ddt` parameterization, but neither the unittest nor pytest xfail mechanisms interact with that. If `@pytest.mark.parametrized` were used, this could be done. But that does not work on methods of test classes that derive from unittest.TestCase, including those in this project that indirectly derive from it by deriving from TestBase. The TestBase base class cannot be removed without overhauling many tests, due to fixtures it provides such as rorepo. So this marks too many tests as xfail, but in doing so allows test runs to pass while still exercising and showing status on all the tests, allowing result changes to be observed easily.
-
Run test_commit_msg_hook_success on more systems
This changes a default Windows skip of test_commit_msg_hook_success to an xfail, and makes it more specific, expecting failure only when either bash.exe is unavailable (definitely expected) or when bash.exe is the WSL bash wrapper in System32, which fails for some reason even though it's not at all clear it ought to. This showcases the failures rather than skipping, and also lets the test pass on Windows systems where bash.exe is something else, including the Git Bash bash.exe that native Windows CI would use.
-
No longer skip test_index_mutation on Cygwin
As it seems to be working now on Cygwin (maybe not native Windows).
-
Report encoding error in test_add_unicode as error
This makes the test explicitly error out, rather than skipping, if it appears the environment doesn't support encoding Unicode filenames. Platforms these days should be capable of that, and reporting it as an error lessens the risk of missing a bug in the test code (that method or a fixture) if one is ever introduced. Erroring out will also make it easier to see the details in the chained UnicodeDecodeError exception. This does not affect the behavior of GitPython itself. It only changes how a test reports an unusual condition that keeps the test\ from being usefully run.
-
-
Report <2.5.1 in test_linked_worktree_traversal as error
Although GitPython does not require git >=2.5.1 in general, and this does *not* change that, this makes the unavailability of git 2.5.1 or later an error in test_linked_worktree_traversal, where it is needed to exercise that test, rather than skipping the test. A few systems, such as CentOS 7, may have downstream patched versions of git that remain safe to use yet are numbered <2.5.1 and do not have the necesary feature to run this test. But by now, users of those systems likely anticipate that other software would rely on the presence of features added in git 2.5.1, which was released over 7 years ago. As such, I think it is more useful to give an error for that test, so the test's inability to be run on the system is clear, than to automatically skip the test, which is likely to go unnoticed.
-
-
Express known test_depth failure with xfail
Rather than skipping, so it becomes known if the situation changes.
-
Remove no-effect
@skipIfon test_untracked_filesIt looked like test_untracked_files was sometimes skipped, and specifically that it would be skipped on Cygwin. But the `@skipIf` on it had the condition: HIDE_WINDOWS_KNOWN_ERRORS and Git.is_cygwin() HIDE_WINDOWS_KNOWN_ERRORS can only ever be true if it is set to a truthy value directly (not an intended use as it's a "constant"), or on native Windows systems: no matter how the environment variable related to it is set, it's only checked if is_win, which is set by checking os.name, which is only "nt" on native Windows systems, not Cygwin. So whenever HIDE_WINDOWS_KNOWN_ERRORS is true Git.is_cygwin() will be false. Thus this condition is never true and the test was never being skipped anyway: it was running and passing on Cygwin. -
Make 2 more too-low git version skips into errors
In the tests only, and not in any way affecting the feature set or requirements of GitPython itself. This is similar to, and with the same reasoning as, cf5f1dc.
-
Update test_root_module Windows skip reason
The current cause of failure is different from what is documented in the skip reason.
-
Change test_root_module Windows skip to xfail
And rewrite the reason to give more useful information. (The new reason also doesn't state the exception type, because that is now specified, and checked by pytest, by being passed as "raises".)
-
Update test_git_submodules_and_add_sm_with_new_commit skip reason
This is working on Cygwin, so that old reason no longer applies. (The test was not being skipped on Cygwin, and was passing.) It is not working on native Windows, due to a PermissionError from attempting to move a file that is still open (which Windows doesn't allow). That may have been the original native Windows skip reason, but the old AppVeyor CI link for it is broken or not public. This makes the reason clear, though maybe I should add more details.
-
Change test_git_submodules_and_add_sm_with_new_commit Windows skip to…
… xfail And improve details. The xfail is only for native Windows, not Cygwin (same as the old skip was, and still via checking HIDE_WINDOWS_KNOWN_ERRORS). This change is analogous to the change in c1798f5, but for test_git_submodules_and_add_sm_with_new_commit rather than test_root_module.
-
Run the tests in test_tree on Windows
This stops skipping them, as they are now working.
-
Add missing raises keyword for test_depth xfail
I had forgotten to do this earlier when converting from skip to xfail. Besides consistency with the other uses of xfail in the test suite, the benefit of passing "raises" is that pytest checks that the failure gave the expected exception and makes it a non-expected failure if it didn't.
-
-
-
-
Try to work in all LF on Cygwin CI
+ Style tweak and comment to clarify the "Limit $PATH" step.
-
Commits on Sep 26, 2023
-
Remove the recently added "Limit $PATH" step
I had put that step in the Cygwin workflow for purposes of experimentation, and it seemed to make clearer what is going on, but really it does the opposite: it's deceptive because Cygwin uses other logic to set its PATH. So this step is unnecessary and ineffective at doing what it appears to do.
-
Further reduce differences between test workflows
This makes the two CI test workflows more similar in a couple of the remaining ways they differ unnecessarily. This could be extended, and otherwise improved upon, in the future.
-
Merge pull request #1679 from EliahKagan/verbose-ci
Make clear every test's status in every CI run
Commits on Sep 27, 2023
-
-
Merge pull request #1680 from EliahKagan/readme-license-link
Fix new link to license in readme
-
-
Drop flake8 suppressions that are no longer needed
+ Remove the comments that documented those old suppressions + Format the .flake8 file more readably
-
Merge pull request #1681 from EliahKagan/more-flake8
Drop unneeded flake8 suppressions
Commits on Oct 1, 2023
-
Drop claim about Cygwin not having git-daemon
On a current Cygwin system with git 2.39.0 (the latest version offered by the Cygwin package manager), git-daemon is present, with the Cygwin path /usr/libexec/git-core/git-daemon.exe. In addition, the cygwin-test.yml workflow does not take any special steps to allow git-daemon to work, but all tests pass in it even without skipping or xfailing tests that seem related to git-daemon. The git_daemon_launched function in test/lib/helper.py only invokes git-daemon directly (rather than through "git daemon") when is_win evaluates true, which only happens on native Windows systems, not Cygwin, which is treated the same as (other) Unix-like systems and still works. So maybe Cygwin git-daemon was never a special case. Whether or not it was, the message about git-daemon needing to be findable in a PATH search is also under an is_win check, and thus is never shown on Cygwin. So I've removed the Cygwin part of that message. (Because the path shown is a MinGW-style path, I have kept the wording about that being for MinGW-git, even though it is no longer needed to disambiguate the Cygwin case.)
-
Allow base_daemon_path to be normalized for Cygwin
Since the Cygwin git-daemon can be used.
Commits on Oct 2, 2023
-
Merge pull request #1684 from EliahKagan/daemon
Update instructions and test helpers for git-daemon
-
Fix the name of the "executes git" test
That test is not testing whether or not a shell is used (nor does it need to test that), but just whether the library actually runs git, passes an argument to it, and returns text from its stdout.
-
In the Popen calls in Git.execute, for all combinations of allowed values for Git.USE_SHELL and the shell= keyword argument.
-
Test if whether a shell is used is logged
The log message shows "Popen(...)", not "execute(...)". So it should faithfully report what is about to be passed to Popen in cases where a user reading the log would otherwise be misled into thinking this is what has happened. Reporting the actual "shell=" argument passed to Popen is also more useful to log than the argument passed to Git.execute (at least if only one of them is to be logged).
-
Fix tests so they don't try to run "g"
Both new shell-related tests were causing the code under test to split "git" into ["g", "i", "t"] and thus causing the code under test to attempt to execute a "g" command. This passes the command as a one-element list of strings rather than as a string, which avoids this on all operating systems regardless of whether the code under test has a bug being tested for. This would not occur on Windows, which does not iterate commands of type str character-by-character even when the command is run without a shell. But it did happen on other systems. Most of the time, the benefit of using a command that actually runs "git" rather than "g" is the avoidance of confusion in the error message. But this is also important because it is possible for the user who runs the tests to have a "g" command, in which case it could be very inconvenient, or even unsafe, to run "g". This should be avoided even when the code under test has a bug that causes a shell to be used when it shouldn't or not used when it should, so having separate commands (list and str) per test case parameters would not be a sufficient solution: it would only guard against running "g" when a bug in the code under test were absent.
-
Extract shared test logic to a helper
This also helps mock Popen over a smaller scope, which may be beneficial (especially if it is mocked in the subprocess module, rather than the git.cmd module, in the future).
-
Use the mock backport on Python 3.7
Because mock.call.kwargs, i.e. the ability to examine m.call_args.kwargs where m is a Mock or MagicMock, was introduced in Python 3.8. Currently it is only in test/test_git.py that any use of mocks requires this, so I've put the conditional import logic to import mock (the top-level package) rather than unittest.mock only there. The mock library is added as a development (testing) dependency only when the Python version is lower than 3.8, so it is not installed when not needed. This fixes a problem in the new tests of whether a shell is used, and reported as used, in the Popen call in Git.execute. Those just-introduced tests need this, to be able to use mock_popen.call_args.kwargs on Python 3.7.
There are no files selected for viewing