Re: Enhancements to git-protocoll

[Sitaram Chamarty <sitaramc@gmail.com>]

On Mon, Jul 30, 2012 at 6:51 AM, Shawn Pearce <spearce@spearce.org> wrote:
> On Sun, Jul 29, 2012 at 6:04 PM, Sitaram Chamarty <sitaramc@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

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