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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 2, 2008, 02:31 UTC
Message-ID: <7vbq85555z.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1199216375-22161-1-git-send-email-pdebie@ai.rug.nl>

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

Show 8 quoted lines

> 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).