Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Dec 1, 2009, 17:19 UTC
Message-ID: <20091201171908.GA15436@Knoppix>
In-Reply-To: <20091201165245.GF21299@spearce.org>

On Tue, Dec 01, 2009 at 08:52:45AM -0800, Shawn O. Pearce wrote:

Show 9 quoted lines

> Sverre Rabbelier <srabbelier@gmail.com> wrote:
> > On Tue, Dec 1, 2009 at 14:57, Ilari Liusvaara
> > <ilari.liusvaara@elisanet.fi> wrote:
> > > This series implements extensions to remote helpers for carrying smary
> > > transports. It is against next, because master doesn't contain necressary
> > > patches (the allow specifying remote helper in url one).
> > 
> > Could you please explain how this relates to Shawn's smart http series
> > and the sr/vcs-helper series?

Ability to easily implement smart transports with underlying full-duplex connection. The smart http stuff has loads of code to reimplement smart transport client side.

Show 5 quoted lines

> Or better, why this is even necessary?
> 
> I thought git:// over TCP is pretty simple and efficient, and fairly
> widely deployed.  Smart http(s):// will be in 1.6.6 and available
> soon, and isn't all that ugly.

I consider the authentication parts of smart http pretty ugly. TLS has some
nicer methods, but support for those is nonexistent. Also, I consider piggy-
backing on HTTP when you can have full-duplex connectivity ugly.

> Since the introduction of git:// nobody has asked for another
> protocol... other than wanting to make http:// as efficient as
> git:// is.  Which is now done.

Incorrect. I have seen requests for gits:// (and in fact, I have plans to implement that protocol).

> So why do we need this?

For instance, to support new types of authentication for smart transports without patching client git binaries (SSH has lots of failure modes that are quite nasty to debug) or abusing GIT_PROXY (yuck).

If the server can also handle authentication, it has a lot better idea where things go wrong and can give better errors to logs or to client (of course, not too much can be leaked to client or it will be too useful for attack, but that's seperate topic).

> The sr/vcs-helper series makes sense if you want to make SVN, Hg,
> or P4 remotes act transparently like Git remotes.  But that's not
> embedding the git:// protocol inside of another protocol, its doing a
> full up conversion from a non-Git set of semantics to Git semantics.

This is not about embedding git:// protol inside another. Its about carrying the subprotocols. These transports share with git:// as much as file:// and ssh:// share with git:// (note that service request is given as command, not inside data pipe).

And IIRC, the only thing this needs from sr/vcs-helper is the patch to allow selecting helper with URL. The first versions of series did contain self-standing functionality equivalent to that, but that got dropped as equivalent functionality appeared in upstream.

-Ilari