{"thread":{"id":"11442","subject":"[PATCH] Let transport.c use git without a dash","startedAt":"2008-01-01T19:39:35Z","lastAt":"2008-01-02T02:31:52Z","messageCount":2,"participants":["Pieter de Bie","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"64302","messageId":"1199216375-22161-1-git-send-email-pdebie@ai.rug.nl","threadId":"11442","inReplyTo":null,"subject":"[PATCH] Let transport.c use git without a dash","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-01-01T19:39:35Z","receivedAt":"2008-01-01T19:39:35Z","isPatch":true,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"This fixes transport.c by using \"git upload-pack\" and \"git receive pack\".\nUsing the old dashed form, git fetch would fail on a remote installation where\nthe git binaries are installed in a separate dir\n---\n\nI think this might have been on the list before, but then it was never applied\nto master. git fetch fails when you have used make gitexecdir=/somewhereelse\non the remote side, as it can't find git-upload-pack.\n\n\n transport.c |    4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/transport.c b/transport.c\nindex 4e151a9..ad4c7e0 100644\n--- a/transport.c\n+++ b/transport.c\n@@ -721,10 +721,10 @@ struct transport *transport_get(struct remote *remote, const char *url)\n \t\tret->disconnect = disconnect_git;\n \n \t\tdata->thin = 1;\n-\t\tdata->uploadpack = \"git-upload-pack\";\n+\t\tdata->uploadpack = \"git upload-pack\";\n \t\tif (remote && remote->uploadpack)\n \t\t\tdata->uploadpack = remote->uploadpack;\n-\t\tdata->receivepack = \"git-receive-pack\";\n+\t\tdata->receivepack = \"git receive-pack\";\n \t\tif (remote && remote->receivepack)\n \t\t\tdata->receivepack = remote->receivepack;\n \t}\n-- \n1.5.4.rc2.3.gbe5a8-dirty\n"},{"id":"64309","messageId":"7vbq85555z.fsf@gitster.siamese.dyndns.org","threadId":"11442","inReplyTo":"1199216375-22161-1-git-send-email-pdebie@ai.rug.nl","subject":"Re: [PATCH] Let transport.c use git without a dash","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-02T02:31:52Z","receivedAt":"2008-01-02T02:31:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pieter de Bie <pdebie@ai.rug.nl> writes:\n\n> This fixes transport.c by using \"git upload-pack\" and \"git receive pack\".\n> Using the old dashed form, git fetch would fail on a remote installation where\n> the git binaries are installed in a separate dir\n> ---\n>\n> I think this might have been on the list before, but then it was never applied\n> to master. git fetch fails when you have used make gitexecdir=/somewhereelse\n> on the remote side, as it can't find git-upload-pack.\n\nTwo questions.\n\n (1) There has long been a support for specifying where your\n     out-of-PATH receive-pack and upload-pack are to be found.\n     Is it inadequate, and if so why?\n\n (2) data->receivepack is copied to args.receivepack in\n     git_transport_push() and then eventually given as prog\n     parameter to git_connect(), which is sent to the shell on\n     the other end.  If the git restricted shell is in use, that\n     is compared to the list of commands shell.c::cmd_list[];\n     and separating \"git-receive-pack\" into two words like your\n     patch would break it, I suspect.  Have you tested this\n     codepath?\n\nIn the longer term (definitely before 1.6.0), we should rethink\nthe way --receive-pack (given to \"git push\") and --upload-pack\n(given to \"git fetch\") options are handled.  We are heading\ntowards \"a single git binary to rule them all\", so it might make\nsense to deprecate these two options and instead have the caller\nspecify the path to \"git\" itself (which in turn knows how to\ninvoke receive-pack and upload-pack subcommands).\n"}]}