It didn't mention how expanded use may require directories like `mingw64/bin` to be added to searched locations, and also was somewhat hard to read. This adds that and rephrases.
Unified · Split
| @@ -71,10 +71,10 @@ const BIN_DIR_FRAGMENTS: &[&str] = &["bin", "usr/bin"]; · 70 unmodified lines | |||
| 71 | /// does, which is the case unless it is overridden by setting `GIT_EXEC_PATH` to an unusual value. | 71 | /// does, which is the case unless it is overridden by setting `GIT_EXEC_PATH` to an unusual value. |
| 72 | /// | 72 | /// |
| 73 | /// This is currently only used (and only exercised in tests) for finding `sh.exe`. It may be used | 73 | /// This is currently only used (and only exercised in tests) for finding `sh.exe`. It may be used |
| 74 | /// to find other executables in the future, but may require adjustment. (In particular, depending | 74 | /// to find other executables in the future, but may require adjustment. In particular, depending |
| 75 | /// on the desired semantics, it should possibly also check inside a `cmd` directory, possibly also | 75 | /// on the desired semantics, it should possibly also check inside a `cmd` directory; directories |
| 76 | /// check inside `super::core_dir()` itself, and could safely check the latter location even if its | 76 | /// like `<platform>/bin`, for any applicable variants (such as `mingw64`); and `super::core_dir()` |
| 77 | /// value is not suitable to use in inferring any other paths.) | 77 | /// itself, which it could safely check even if its value is not safe for inferring other paths. |
| 78 | fn find_git_associated_windows_executable(stem: &str) -> Option<OsString> { | 78 | fn find_git_associated_windows_executable(stem: &str) -> Option<OsString> { |
| 79 | let git_root = git_for_windows_root()?; | 79 | let git_root = git_for_windows_root()?; |
| 80 | 80 | ||