Pieter de Bie <pdebie@xxxxxxxxx> 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).
-
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
