You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the USE_SHELL docstring:
- Restore the older wording "when executing git commands" rather
than "to execute git commands". I've realized that longer phrase,
which dates back to the introduction of USE_SHELL in 1c2dd54, is
clearer, because readers less familiar with GitPython's overall
design and operation will still not be misled into thinking
USE_SHELL ever affects whether GitPython uses an external git
command, versus some other mechanism, to do something.
- Give some more information about why USE_SHELL = True is unsafe
(though further revision or clarification may be called for).
- Note some non-obvious aspects of USE_SHELL, that some of the way
it interacts with other aspects of GitPython is not part of what
is or has been documented about it, and in practice changes over
time. The first example relates to gitpython-developers#1792; the second may help
users understand why code that enables USE_SHELL on Windows, in
addition to being unsafe there, often breaks immediately on other
platforms; the third is included so the warnings in the expanded
docstring are not interpreted as a new commitment that any shell
syntax that may have a *desired* effect in some application will
continue to have the same effect in the future.
- Cover a second application that might lead, or have led, to
setting USE_SHELL to True, and explain what to do instead.
In test_successful_default_refresh_invalidates_cached_version_info:
- Rewrite the commented explanation of a special variant of that
second application, where the usual easy alternatives are not
used because part of the goal of the test is to check a "default"
scenario that does not include either of them. This better
explains why that choice is made in the test, and also hopefully
will prevent anyone from thinking that test is a model for
another situation (which, as noted, is unlikely to be the case
even in unit tests).
0 commit comments