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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 04, 2009 at 10:37:13AM -0800, Shawn O. Pearce wrote:
> Ilari Liusvaara <ilari.liusvaara@xxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]