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

[Ilari Liusvaara <ilari.liusvaara@elisanet.fi>]

On Fri, Dec 04, 2009 at 10:37:13AM -0800, Shawn O. Pearce wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> 
> Why not 'fallback' to remain consistent with this protocol and many
> others in git where we stick to lowercase ASCII?

Changed.
 
> Why is the initial advertisement special?  If the helper always
> flushes both sides, it shouldn't ever deadlock the protocol.  Also,
> note that a helper should be able to implement a tiny delay like
> Nagle's algorithm does in TCP.  It just can't sit on a byte forever.

That's just extremely badly worded. The point is that only place where
buffering has even seemed useful is initial adverts. Those can
really trigger large numbers of small transfers if unbuffered.

Granted, small delay should work quite well.

I'll reword it.

> This hunk appears to be unrelated.  And actually, if transport has
> no remote, shouldn't the arg here be NULL so the helper gets only
> 1 argument and not 2 arguments?

Actually, it can't be NULL (the code would have already die()'d in
that case). Fixed.

> I think exec winds up defaulting to name if --upload-pack was not
> used on the command line, and remote.$name.uploadpack was not set.
> See transport.c where you initialize the git options struct, these
> fields were defaulted in.

Actually, there was bug in initializing git options struct. It was
properly initialized if one used foo://, but not with foo::bar://.
Tripping it caused NULL exec to be passed if you didn't override.
I fixed that bug and now the servpath code has just strcmp.

> My point is, we shouldn't send option servpath to the helper if
> name is equal to servpath, because the helper might not support
> servpath and the option command will issue a warning above for no
> reason at all.

This is exactly what happens (and yes, I tested). No --receive-pack
doesn't trip warning, with --receive-pack it does.

-Ilari