Searching git programs only in the highest priority location is sufficient. It does not make sense that some of the required programs are located at the highest priority location but other programs are picked up from a lower priority exec-path. If exec-path is overridden a complete set of commands should be provided, otherwise several different versions could get mixed, which is likely to cause confusion. If a user explicitly overrides the default location (by --exec-path or GIT_EXEC_PATH), we now expect that all the required programs are found there. Instead of adding the directories "argv_exec_path", "getenv(EXEC_PATH_ENVIRONMENT)", and "system_path(GIT_EXEC_PATH)" to PATH, we now rely on git_exec_path(), which implements the same order, but only returns the highest priority location to search for executables. Accessing only the location with highest priority is also required for testing executables built with RUNTIME_PREFIX. The call to system_path() should be avoided if RUNTIME_PREFIX is set and the executable is not installed at its final destination. Because we test before installing, we want to avoid calling system_path() during tests. The modifications in this commit avoid calling system_path(GIT_EXEC_PATH) if a higher-priority location is provided, which is the case when running the tests. Signed-off-by: Steffen Prohaska <prohaska@xxxxxx> --- exec_cmd.c | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/exec_cmd.c b/exec_cmd.c index 89931e4..d9408db 100644 --- a/exec_cmd.c +++ b/exec_cmd.c @@ -78,9 +78,7 @@ void setup_path(void) const char *old_path = getenv("PATH"); struct strbuf new_path = STRBUF_INIT; - add_path(&new_path, argv_exec_path); - add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT)); - add_path(&new_path, system_path(GIT_EXEC_PATH)); + add_path(&new_path, git_exec_path()); add_path(&new_path, argv0_path); if (old_path) -- 1.6.1.87.g15624 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html