Daniel Barkalow <barkalow@xxxxxxxxxxxx> 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. -- 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