Re: [RFC PATCH 4/8] Support remote helpers implementing smart transports

From: Shawn O. Pearce <spearce@spearce.org>
Date: Dec 3, 2009, 19:42 UTC
Message-ID: <20091203194242.GD23281@spearce.org>
In-Reply-To: <20091202201008.GB11301@Knoppix>

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:

Show 6 quoted lines

> On Wed, Dec 02, 2009 at 09:04:57AM -0800, Shawn O. Pearce wrote:
> > Modify transport-helper.c to allow pushing TRANS_OPT_UPLOADPACK and
> > TRANS_OPT_RECEIVEPACK down into the helper via the option capability.
> 
> NAK. Modified _process_connect_or_invoke (now _process_connect) to pass
> new option that appiles to connecting all subprotocols (if needed).

...

> And from helper POV, all subprotocols should appear identical from
> layer 6 POV so it doesn't make sense to diffrentiate between path
> for upload-pack and receive-pack (or upload-archive!).

That may be true, but the remote.origin.uploadpack and remote.origin.receivepack configuration options exist and are passed through as these option uploadpack and option receivepack callbacks.

If you want to pass through a single option with the remote program
name, you need to do that immediately before the connect invoke
occurs, and instead buffer the two different configuration options
in the struct transport.  I think that would make the series messier
than it is.

-- 
Shawn.