On Wed, Apr 20, 2016 at 04:46:55PM -0400, David Turner wrote: > As you note, it appears that git-daemon does sort-of have support for > extra args -- see parse_host_arg. So it wouldn't be hard to add > something here. Unfortunately, current versions of git die on unknown > args. So this change would not be backwards-compatible. We could put > a decider on it so that clients would only try it when explicitly > enabled. Or we could have clients try it with, and in the event of an > error, retry without. Neither is ideal, but both are possible. Right. This ends up being the same difficulty that the v2 protocol encountered; how do you figure out what you can speak without resorting to expensive fallbacks, when do you flip the switch, do you remember the protocol you used last time with this server, etc. Which isn't to say it's necessarily a bad thing. Maybe the path forward instead of v2 is to shoe-horn this data into the pre-protocol conversation, and go from there. The protocol accepts that "somehow" it got some extra data from the transport layer, and acts on its uniformly. > If I read this code correctly, git-over-ssh will pass through arbitrary > arguments. So this should be trivial. It does if you are ssh-ing to a real shell-level account on the server, but if you are using git-shell or some other wrapper to restrict clients from running arbitrary commands, it will likely reject it. -Peff -- 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