On Mon, Jul 30, 2012 at 11:58 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Shawn Pearce <spearce@xxxxxxxxxxx> writes: > >>> 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. > > Heh. While I do not particularly consider auto-creation-upon-push a > useful thing to begin with (after all, once you created a > repository, you would want ways to manage it, setting up ACL for it > and stuff like that, so adding a "create" command to the management > interface suite would be a more natural direction to go), as long as > we are discussing a hack that involves hooks, I do not think your > observation is a show-stopper downside. > > The hook can interact with the end user over the back channel and > decide to abort the transaction, while leaving some clue in the > repository that is pre-agreed between the gitlite server and the > hook. When gitolite culls the process with wait4(2), it could > notice that "clue", read the wish of the hook that the repository > needs to be removed from it, and remove the repository. Up to that > point, there is no real data transferred, so there isn't much wasted > time or network resource anyway. > >> 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? > > I do not think the details of how the extra information is passed > via the Git at the receiving end to its surrounding matters that > much. It would even work fine if we let the hook to talk with the > end user sitting at the "git push" end, by using two extra sidebands > to throw bits between them, while the Git process that spawned the > hook acts as a relay, to establish a custom bi-di conversation (but > again, I do not think it is useful, because such an out of band > conversation cannot affect the outcome of the main protocol exchange > in a meaningful way other than aborting). > > Or you could export environment variables, which would be far more > limiting with respect to the nature of the data (i.e. needs to be > free of NUL) and the size of data you can pass. The limitation may > actually be a feature to discourage people from doing wacky things, > though. > >> `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. > > I think using the same "extra args on the command line" would be a > good way to upgrade the protocol version in a way the current > "capability" system does not allow us to (namely, stop the party > that accepts the connection from immediately advertising its refs). More importantly from gitolite's point of view, this is the only way gitolite can see those variables in some situations, because gitolite runs *before* git, (and then again later via the update hook for pushes). >> 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. > > That way lies madness, and at that point, you are better off doing a > proper protocol extension by registering a new capability and defining > the semantics for it. -- Sitaram -- 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