[prev in list] [next in list] [prev in thread] [next in thread]
List: git
Subject: Re: [RFC/PATCH 2/5] upload-pack: support out of band client capability requests
From: "Kyle J. McKay" <mackyle () gmail ! com>
Date: 2015-02-28 22:36:18
Message-ID: BA483DD3-3AD5-4B52-8379-F9FBA9A9305E () gmail ! com
[Download RAW message or body]
On Feb 28, 2015, at 03:22, Duy Nguyen wrote:
> The client should only trigger this behavior when it knows the server
> can deal with it. And that is possible because in the last fetch, the
> server has told the client that it's capable of receiving this
> capabilities argument. Backward compatibility is a concern at client
> side, not server side.
>
>> I've looked at those links and it's unclear to me how they support an
>> out-of-band option for ssh, they seem to be targeted at git-
>> daemon. Maybe
>> there's another reference?
>
> For ssh, I think connect.c is the one that constructs and executes
> ssh command.
This I assume you're referring to this change in connect.c from [1]:
@@ -729,6 +734,8 @@ struct child_process *git_connect(int fd[2], const
char *url,
conn->use_shell = 1;
}
argv_array_push(&argv, cmd.buf);
+ if (service_flags)
+ argv_array_push(&argv, service_flags);
conn->argv = argv.argv;
if (start_command(conn))
die("unable to fork");
That's not going to work for ssh servers running a stock git-shell and
I haven't seen any updates to shell.c to match. git-shell does not
allow anything other than one argument to be passed to git-upload-pack/
git-receive-pack.
When shell.c calls do_generic_cmd and it calls sq_dequote on its
argument that contains "'dir' 'service-flags'" it's going to return
NULL and shell.c will die("bad argument"). So I don't see how this
supports ssh as-is even if you know in advance the server supports the
new protocol. I don't see any changes to shell.c in that uploadpack2
branch nor in this patch series.
-Kyle
[1] https://github.com/pclouds/git/commit/20d048e5fc650b20fdc7dd8bbe35cb8510ac9c50
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic