Re: [RFC PATCH v2 08/16] remote-helpers: Support custom transport options

["Shawn O. Pearce" <spearce@spearce.org>]

Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 13 Oct 2009, Shawn O. Pearce wrote:
> > 
> > For fetch it defaults to "on", but for push I think it defaults
> > to "off".
> 
> Nope, on ~line 849 of transport.c, it gets set for all native-transport 
> handlers, and never gets turned off. Looks like a misconversion 2 years 
> ago defaulting "data->thin" to 1 instead of 0, but it seems not to have 
> caused problems.

The rationale for why it was off by default on push was to avoid
making suboptimal packs on the server due to needing to complete
the thin pack out.  If its been off for 2 years I guess its not
that big of a deal.  We can probably leave thin out then and just
start deprecating the option.


Actually... right now I'm more concerned about why a negotiation
over the native protocol is making the client mention "have v1.5.5"
(yes, the tag object) when I'm trying to fetch between two git.git
repositories that are only 1 Junio work day apart.

In the grand scheme of things over TCP or SSH, that's a few extra
have lines.  Over the stateless HTTP its why the final request is
bloating out to 8 KiB worth of have lines.  In one Junio work day
we should only be seeing a few hundred new objects, yea pu rewinds,
but v1.5.5 isn't the best common base available to us... IMHO we
shouldn't have even mentioned it.

But fixing this is independent of smart HTTP, I'll try to circle
back later and look at why I'm seeing this oddity in the common
commit negotiation.

-- 
Shawn.