On Sun, Jul 29, 2012 at 6:04 PM, Sitaram Chamarty <sitar...@gmail.com> wrote:
> Of course this will only work with ssh. None of what Fredrik has so
> far suggested would possibly work on smart http without even more
> hacks, I think.
Now that we have smart HTTP, and its somewhat popular for sites to
deploy with, we need to carefully consider all future protocol changes
to make sure they are compatible with the HTTP one. Since the HTTP is
single request/response model, its hard to implement a conversation
with the end-user.
One thing I would like to do with the protocol is add custom site
specific extensions to the protocol, where hooks are able to advertise
in the initial capability list something like a namespace prefix that
`git push` can use to offer site specific command line flags from:
....00000000... HEAD^{} report-status delete-refs side-band-64k
ofs-delta hook=gitolite
and the client seeing this would recognize a push command like:
git push -Lgitolite,create-repository URL master
passing the string "gitolite,create-repository" as data in the header
of the push request. gitolite would need to scan more than just the
git receive-pack command line from SSH to see this data, but you can
use it to implement an "are you sure you want to create this
repository" exchange by failing a push with sideband information
telling the user to reinvoke push with the create-repository flag if
they really mean to create it.
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. From what I
understand, Mercurial already has something like this in their push
system for hooks to accept additional data one-way 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
