[PATCH] Let transport.c use git without a dash

[PATCH] Let transport.c use git without a dash

[Pieter de Bie]

This fixes transport.c by using "git upload-pack" and "git receive pack".
Using the old dashed form, git fetch would fail on a remote installation where
the git binaries are installed in a separate dir
---

I think this might have been on the list before, but then it was never applied
to master. git fetch fails when you have used make gitexecdir=/somewhereelse
on the remote side, as it can't find git-upload-pack.


 transport.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/transport.c b/transport.c
index 4e151a9..ad4c7e0 100644
--- a/transport.c
+++ b/transport.c
@@ -721,10 +721,10 @@ struct transport *transport_get(struct remote *remote, const char *url)
 		ret->disconnect = disconnect_git;
 
 		data->thin = 1;
-		data->uploadpack = "git-upload-pack";
+		data->uploadpack = "git upload-pack";
 		if (remote && remote->uploadpack)
 			data->uploadpack = remote->uploadpack;
-		data->receivepack = "git-receive-pack";
+		data->receivepack = "git receive-pack";
 		if (remote && remote->receivepack)
 			data->receivepack = remote->receivepack;
 	}
-- 
1.5.4.rc2.3.gbe5a8-dirty

Re: [PATCH] Let transport.c use git without a dash

[Junio C Hamano]

Pieter de Bie <pdebie@ai.rug.nl> writes:

> This fixes transport.c by using "git upload-pack" and "git receive pack".
> Using the old dashed form, git fetch would fail on a remote installation where
> the git binaries are installed in a separate dir
> ---
>
> I think this might have been on the list before, but then it was never applied
> to master. git fetch fails when you have used make gitexecdir=/somewhereelse
> on the remote side, as it can't find git-upload-pack.

Two questions.

 (1) There has long been a support for specifying where your
     out-of-PATH receive-pack and upload-pack are to be found.
     Is it inadequate, and if so why?

 (2) data->receivepack is copied to args.receivepack in
     git_transport_push() and then eventually given as prog
     parameter to git_connect(), which is sent to the shell on
     the other end.  If the git restricted shell is in use, that
     is compared to the list of commands shell.c::cmd_list[];
     and separating "git-receive-pack" into two words like your
     patch would break it, I suspect.  Have you tested this
     codepath?

In the longer term (definitely before 1.6.0), we should rethink
the way --receive-pack (given to "git push") and --upload-pack
(given to "git fetch") options are handled.  We are heading
towards "a single git binary to rule them all", so it might make
sense to deprecate these two options and instead have the caller
specify the path to "git" itself (which in turn knows how to
invoke receive-pack and upload-pack subcommands).