Skip to content

Commit

Permalink
Clarify why an initial failing git command can be set
Browse files Browse the repository at this point in the history
This clarifies the comment that explains the significance of
setting the Git.GIT_PYTHON_GIT_EXECUTABLE attribute when running it
did not suceeed but it hadn't been set before (or was set to None).

This happens in the code path in Git.refresh where has_git is False
and old_git is None, provided the refresh mode doesn't call for the
initial refresh to raise an exception on failure.

It was previously described in terms of a "first" and "second"
import, but as discussed in #1804, the rationale and effect were
not altogether clear.
  • Loading branch information
EliahKagan committed Jan 24, 2024
1 parent d28c20b commit e80fc5f
Showing 1 changed file with 4 additions and 3 deletions.
7 changes: 4 additions & 3 deletions git/cmd.py
Original file line number Diff line number Diff line change
Expand Up @@ -475,9 +475,10 @@ def refresh(cls, path: Union[None, PathLike] = None) -> bool:
)
raise ImportError(err)

# We get here if this was the init refresh and the refresh mode was not
# error. Go ahead and set the GIT_PYTHON_GIT_EXECUTABLE such that we
# discern the difference between a first import and a second import.
# We get here if this was the initial refresh and the refresh mode was
# not error. Go ahead and set the GIT_PYTHON_GIT_EXECUTABLE such that we
# discern the the difference between the first refresh at import time
# and subsequent calls to refresh.
cls.GIT_PYTHON_GIT_EXECUTABLE = cls.git_exec_name
else:
# After the first refresh (when GIT_PYTHON_GIT_EXECUTABLE is no longer
Expand Down

0 comments on commit e80fc5f

Please sign in to comment.