user/sven/git.git/exec_cmd.c, branch v1.6.4.5

Merge branch 'js/maint-1.6.0-exec-path-env'

2009-03-26T07:27:03Z

* js/maint-1.6.0-exec-path-env: Propagate --exec-path setting to external commands via GIT_EXEC_PATH

Propagate --exec-path setting to external commands via GIT_EXEC_PATH

2009-03-22T04:45:14Z

Let PATH0=$PATH that was set before the invocation. Let /foo be a build directory. Let /pfx be the installation prefix. Let pfxexecpath=/pfx/libexec/git-core. The following is going on when 'git --exec-path=/foo gc' is invoked: 1. git sets PATH=/foo:$PATH0 using the path from --exec-path 2. gc execs 'git repack' (note: no dash). 3. Since there is a git in /foo (it's a build directory), /foo/git is taken. 4. No explicit exec-path is set this time, hence, this secondary git sets PATH=$pfxexecpath:/foo:$PATH 5. Since 'repack' is not a built-in, execv_dashed_external execs 'git-repack' (note: dash). 6. There is a $pfxexecpath/git-repack, and it is taken. 7. This git-repack runs 'git pack-objects' (note: no dash). 8. There is no git in $pfxexecpath, but there is one in /foo. Hence, /foo/git is run. 9. pack-objects is a builtin, hence, in effect /foo/git-pack-objects is run. As you can see, the way in which we previously set the PATH allowed to mix gits of different vintage. By setting GIT_EXEC_PATH when --exec-path was given on the command line, we reduce the confusion. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

system_path(): simplify using strip_path_suffix(), and add suffix "git"

2009-02-20T06:47:39Z

At least for the author of this patch, the logic in system_path() was too hard to understand. Using the function strip_path_suffix() documents the idea of the code better. The real change is to add the suffix "git", so that a runtime prefix will be computed correctly even when the executable was called in /git/ as is the case in msysGit (Windows insists to search the current directory before the PATH when looking for an executable). Signed-off-by: Johannes Schindelin Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano

Compute prefix at runtime if RUNTIME_PREFIX is set

2009-01-26T08:26:05Z

This commit adds support for relocatable binaries (called RUNTIME_PREFIX). Such binaries can be moved together with the system configuration files to a different directory, as long as the relative paths from the binary to the configuration files is preserved. This functionality is essential on Windows where we deliver git binaries with an installer that allows to freely choose the installation location. If RUNTIME_PREFIX is unset we use the static prefix. This will be the default on Unix. Thus, the behavior on Unix will remain identical to the old implementation, which used to add the prefix in the Makefile. If RUNTIME_PREFIX is set the prefix is computed from the location of the executable. In this case, system_path() tries to strip known directories that executables can be located in from the path of the executable. If the path is successfully stripped it is used as the prefix. For example, if the executable is "/msysgit/bin/git" and BINDIR is "bin", then the prefix computed is "/msysgit". If the runtime prefix computation fails, we fall back to the static prefix specified in the makefile. This can be the case if the executable is not installed at a known location. Note that our test system sets GIT_CONFIG_NOSYSTEM to tell git to ignore global configuration files during testing. Hence testing does not trigger the fall back. Note that RUNTIME_PREFIX only works on Windows, though adding support on Unix should not be too hard. The implementation requires argv0_path to be set to an absolute path. argv0_path must point to the directory of the executable. We use assert() to verify this in debug builds. On Windows, the wrapper for main() (see compat/mingw.h) guarantees that argv0_path is correctly initialized. On Unix, further work is required before RUNTIME_PREFIX can be enabled. Signed-off-by: Steffen Prohaska Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano

Modify setup_path() to only add git_exec_path() to PATH

2009-01-26T08:26:05Z

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 Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano

git_extract_argv0_path(): Move check for valid argv0 from caller to callee

2009-01-26T08:26:05Z

This simplifies the calling code. Signed-off-by: Steffen Prohaska Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano

Refactor git_set_argv0_path() to git_extract_argv0_path()

2009-01-26T08:26:05Z

This commit moves the code that computes the dirname of argv[0] from git.c's main() to git_set_argv0_path() and renames the function to git_extract_argv0_path(). This makes the code in git.c's main less cluttered, and we can use the dirname computation from other main() functions too. [ spr: - split Steve's original commit and wrote new commit message. - Integrated Johannes Schindelin's cca1704897e7fdb182f68d4c48a437c5d7bc5203 while rebasing onto master. ] Signed-off-by: Steve Haslam Signed-off-by: Steffen Prohaska Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano

Move computation of absolute paths from Makefile to runtime (in preparation for RUNTIME_PREFIX)

2009-01-26T08:26:05Z

This commit prepares the Makefile for relocatable binaries (called RUNTIME_PREFIX). Such binaries will be able to be moved together with the system configuration files to a different directory, requiring to compute the prefix at runtime. In a first step, we make all paths relative in the Makefile and teach system_path() to add the prefix instead. We used to compute absolute paths in the Makefile and passed them to C as defines. We now pass relative paths to C and call system_path() to add the prefix at runtime. Signed-off-by: Steffen Prohaska Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano

Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializer

2008-10-12T19:36:19Z

Many call sites use strbuf_init(&foo, 0) to initialize local strbuf variable "foo" which has not been accessed since its declaration. These can be replaced with a static initialization using the STRBUF_INIT macro which is just as readable, saves a function call, and takes up fewer lines. Signed-off-by: Brandon Casey Signed-off-by: Shawn O. Pearce

Refactor, adding prepare_git_cmd(const char **argv)

2008-07-29T06:02:11Z

prepare_git_cmd(const char **argv) adds a first entry "git" to the array argv. The new array is allocated on the heap. It's the caller's responsibility to release it with free(). The code was already present in execv_git_cmd() but could not be used from outside. Now it can also be called for preparing the command list in the MinGW codepath in run-command.c. Signed-off-by: Steffen Prohaska Signed-off-by: Junio C Hamano