On Sun, Jul 29, 2012 at 7:38 PM, Junio C Hamano <gits...@pobox.com> wrote: > Shawn Pearce <spea...@spearce.org> writes: > >> We sort of want this in Gerrit Code Review to pass reviewer names on >> the command line of git push, making it easier for users to upload a >> code review. The idea is similar to what happens with gcc accepting >> linker flags that are just passed onto the linker. > > For reviewer names, authentication cookies and things of that nature > where the extra pieces of information affect the outcome in a way > that does not have to change how the underlying protocol exchange > works, such an additional one-way channel from the pusher to pushee > to carry auxiliary information would be sufficient.
Yes, that is what I was trying to argue. :-) I agree that authentication information is outside of the Git protocol itself. We rely on SSH authentication for SSH and HTTP native authentication methods for HTTP transport. But at least in the HTTP case, the Git client has learned how to set up the authentication data for the user to make it easier to use HTTP authentication. We don't yet support native OAuth 2.0 (ick!) or HTTP cookies as well as we do client side SSL certificates or basic username/password pair. If we want to support additional information from pusher to pushee, this is a "native feature" of Git and should be supported on all native push type transports, with roughly the same semantics everywhere. I don't want to add additional data into X-Git-Foo HTTP headers in HTTP, and as environment variables in SSH, for example. Additional HTTP headers will *probably* transit an HTTP proxy correctly (but there are a lot of broken proxy servers so I don't put it past someone to strip an X-* header they don't think is "safe"). SSH environment variables are icky to set from the client, and server side Git would need to know how it was invoked to decode the correct data and make it available uniformly to repository owner authored hooks. > The server may > decide to accept otherwise forbidden, or reject otherwise permitted, > push based on the extra information given, for example, and that is > an example of an enhancement that does not have to change how the > underlying protocol exchange works. Yes. > The way to expose the extra information parsed by Git to the server > side could be made into calling out to hooks, and at that point, > gitolite would not even have to know about the pack protocol. Good point. The case that spawned this thread however still has a problem with this approach. gitolite would need to create a repository to invoke the receive-pack process within, and install that new hook script into... when the hook was trying to prevent the creation of that repository in the first place. Maybe I am jaded by the way JGit handles the protocol, it is easy for application code to glue into and see things going on in the protocol in ways that are hard to do from git-core. > Perhaps the interface to such a hook may be "hook can tell Git to > abort the communication by exiting non-zero, after giving a message > to its standard output". Perhaps this new channel data is simply passed as arguments to receive-pack on the remote side? An ancient Git would abort hard if passed this flag. An updated Git could set environment variables before calling hooks, making the arguments visible that way. And gitolite can still scrape what it needs from the command line without having to muck about inside of the protocol, but only if it needs to observe this new data from pusher to pushee? `git push -Rfoo=baz host:dest.git master` on the client would turn into `git-receive-pack -Rfoo=baz dest.git` in the SSH and git:// command line, and cause GIT_PUSH_ARG_FOO=baz to appear in the environment of hooks. Over smart HTTP requests would get an additional query parameter of foo=baz. The other hacky idea I had was to use a fake reference and have the client push a structured blob to that ref. The server would decode the blob, and deny the creation of the fake reference, but be able to get additional data from that blob. Its hacky, and I don't like making a new blob on the server just to transport a few small bits of data from the client. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
