summaryrefslogtreecommitdiff
path: root/builtin-apply.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2009-07-09 06:37:35 (GMT)
committerJunio C Hamano <gitster@pobox.com>2009-07-09 08:19:51 (GMT)
commit4ecbc178704ca6c1027a38483e98f5fe493b1322 (patch)
treee5cf8b0e1e660eb837c2e5d98c2071a0a1e3bb57 /builtin-apply.c
parent3125be17d66e65c854249fb6a0c05322798593fe (diff)
downloadgit-4ecbc178704ca6c1027a38483e98f5fe493b1322.zip
git-4ecbc178704ca6c1027a38483e98f5fe493b1322.tar.gz
git-4ecbc178704ca6c1027a38483e98f5fe493b1322.tar.bz2
Makefile: install 'git' in execdirv1.6.4-rc0
When a git command executes a subcommand, it uses the "git foo" form, which relies on finding "git" in the PATH. Normally this should not be a problem, since the same "git" that was used to invoke git in the first place will be found. And if somebody invokes a "git" outside of the PATH (e.g., by giving its absolute path), this case is already covered: we put that absolute path onto the front of PATH. However, if one is using "sudo", then sudo will execute the "git" from the PATH, but pass along a restricted PATH that may not contain the original "git" directory. In this case, executing a subcommand will fail. To solve this, we put the "git" wrapper itself into the execdir; this directory is prepended to the PATH when git starts, so the wrapper will always be found. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin-apply.c')
0 files changed, 0 insertions, 0 deletions