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

From: Jeff King <peff@peff.net>
Date: Dec 2, 2009, 19:39 UTC
Message-ID: <20091202193902.GE30778@coredump.intra.peff.net>
In-Reply-To: <7vy6lldwyo.fsf@alter.siamese.dyndns.org>

On Wed, Dec 02, 2009 at 10:58:39AM -0800, Junio C Hamano wrote:

> After all my main objection is against closing the door to others by one
> particular implementation squating on "remote-http" name and refusing the
> use of that nice, authoritative-sounding name by others.

I would think that it would be useful to use the "remote-http" name as the extra level of indirection (as a symlink, hardlink, or wrapper script to remote-curl). Then you could have competing first-class implementations that would be easy for the user (or package manager) to switch between.

For example, Debian contains versions of curl built against gnutls and against openssl. Right now the debian git package requires the gnutls version. But let's say they ship two packages: git-http-curl-openssl and git-http-curl-gnutls. Then you can install whichever you prefer, and the package will contain the file "git-remote-http" pointing to "git-remote-curl-$whatever".

And yes, if you think about it, this particular situation already works with a hard-coded "git-remote-curl", since both are built on top of curl, and that makes a reasonable name. But now extend it to "you don't want to use curl, but rather some other http library". I don't think we have any interest in providing a non-curl version as part of git itself, but it provides a hook should somebody want to write their own http handler (either using a different library, or maybe a wrapper that does caching, or whatever).

Just my two cents. I don't plan on writing any such third-party remote handlers, but it seems simple enough to leave the door open.

-Peff