Thread (4 messages) flat view 4 messages, 3 authors, 2016-06-15

Re: Enhancements to git-protocoll

From: Sitaram Chamarty <hidden>
Date: 2016-06-15 22:54:22

On Mon, Jul 30, 2012 at 6:51 AM, Shawn Pearce [off-list ref] wrote:
On Sun, Jul 29, 2012 at 6:04 PM, Sitaram Chamarty [off-list ref] wrote:
quoted
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
I would avoid anything that requires gitolite to even *know* the pack
protocol.  They should be orthogonal.

But if you mean this extra info will be added to the command line
itself in some way (or in http terms to the REQUEST_URI, PATH_INFO,
QUERY_STRING, etc) then that's fine.

People who use gitolite already should try "git ls-remote
git@host:testing.git1" instead of the usual "...testing" or
"...testing.git" to see how a trace capability is currently hacked
into gitolite.  Also change the 1 to a 2 then a 3 if you wish.

I'd certainly love a cleaner way of doing this, and what you suggest
seems it will satisfy.
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.


-- 
Sitaram
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help