On Tue, Oct 8, 2013 at 4:44 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> On Tue, Oct 8, 2013 at 3:44 PM, Carlos Martín Nieto <cmn@xxxxxxxx> wrote:
>> diff --git a/send-pack.c b/send-pack.c
>> index 7d172ef..7b88ac8 100644
>> --- a/send-pack.c
>> +++ b/send-pack.c
>> @@ -205,6 +205,8 @@ int send_pack(struct send_pack_args *args,
>> quiet_supported = 1;
>> if (server_supports("agent"))
>> agent_supported = 1;
>> + if (!server_supports("thin-pack"))
>> + args->use_thin_pack = 0;
>
> Hmm.. I think this introduces a regression in C Git because
> receive-pack never advertises "thin-pack" and so "git push" from now
> on will never send thin packs. It's too late now to add thin-pack to
> receive-pack
Or maybe it's not that late. How about you go with your patch and add
thin-pack capability to receive-pack too?
When new "git push" is used against old server, thin pack is disabled.
But that's not a big deal (I hope). The difference is traffic
increases a bit more, but cpu consumption on the server side is also a
bit less. Pushes are usually small, unless you do initial push, which
is complete anyway. So a bit more or less does not really matter in
practice.
We could mitigate the regression a bit by checking agent string and
enable thin-pack for those versions even if thin-pack is not
advertises. That goes back to v1.7.12. We may do the same for some
other popular git servers. And this hack is maintained like 3-4 years,
enough time for new versions to be deployed, then removed.
Hmm?
--
Duy
--
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