Junio C Hamano [off-list ref] wrote:
The daemon expects to see the dashed form and we cannot change older
servers. But when invoking programs on the remote end over SSH, the
command line the client side build is under client's control.
...
quoted hunk ↗ jump to hunk
diff --git a/connect.c b/connect.c
index e92af29..fd1da26 100644
--- a/connect.c
+++ b/connect.c
@@ -589,6 +589,10 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
conn = xcalloc(1, sizeof(*conn));
strbuf_init(&cmd, MAX_CMD_LEN);
+ if (protocol != PROTO_GIT && !strncmp(prog, "git-", 4)) {
+ strbuf_addstr(&cmd, "git ");
+ prog += 4;
+ }
Nack on that implementation.
I think this is a problem for systems based on say gitosis,
or some pattern like it. Day-job doesn't use gitosis, but
has switched to a Perl based forced ssh tool that smells a
lot like gitosis. Gitosis is popular.
github probably uses something similar. But nobody knows (or
probably cares) since they don't release their source.
gitosis is likely looking for "$git-upload-pack '(.*)'$" to be
in the $SSH_ORIGINAL_COMMAND environment variable, if you send
"git upload-pack 'path.git'" I think its going to reject.
What's really bad about your patch is you cannot work around it as a
user by setting --upload-pack on the command line, or in the config,
because down at the very deepest level you are switching the "git-"
to "git " and ignoring what the user has supplied you.
Sorry, but I think this change needs to go higher up, to the default
values that --upload-pack and remote.$name.uploadpack override,
so the user can at least work around it when we break her ability
to use github, gitosis, or anything like it.
--
Shawn.