The --upload-pack option to clone raises the expectation that finding
git-upload-pack on the server side is enough. But git-upload-pack needs
to find git (for forking "git pack-objects") which fails if git is not
in $PATH.
This patch makes git-upload-pack use git_set_argv0_path() so that an
explicitely specified path for git-upload-pack is added to the path
which is used when fork()ing.
Signed-off-by: Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx>
---
upload-pack.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
The corresponding bug was reported by Paul Johnston who wondered why "git clone"
failed when specifying --upload-pack for an out-of-$PATH installation of git.
I'm not sure whether we should encourage this, but the --upload-pack option
clearly gives the impression that git-upload-pack is all that is needed.
I haven't looked at other server side programmes yet regarding this issue,
but "git clone" works fine with this patch in the situation where it
would not without.
diff --git a/upload-pack.c b/upload-pack.c
index e5adbc0..1fb59de 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -615,6 +615,21 @@ int main(int argc, char **argv)
char *dir;
int i;
int strict = 0;
+ const char *cmd = argv[0] && *argv[0] ? argv[0] : "git-upload-pack";
+ char *slash = (char *)cmd + strlen(cmd);
+
+ /*
+ * Take the basename of argv[0] as the command
+ * name, and the dirname as the default exec_path
+ * if we don't have anything better.
+ */
+ do
+ --slash;
+ while (cmd <= slash && !is_dir_sep(*slash));
+ if (cmd <= slash) {
+ *slash++ = 0;
+ git_set_argv0_path(cmd);
+ }
for (i = 1; i < argc; i++) {
char *arg = argv[i];
--
1.6.0.1.308.gede4c
--
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
