Re: [RFC PATCH v2 08/16] remote-helpers: Support custom transport options
From: Shawn O. Pearce <hidden>
Date: 2016-06-15 22:47:33
Daniel Barkalow [off-list ref] wrote:
On Tue, 13 Oct 2009, Shawn O. Pearce wrote:quoted
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.