Shawn Pearce <spea...@spearce.org> 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
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,
> `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).
> 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.
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