On Tue, Oct 8, 2013 at 4:44 PM, Duy Nguyen <pclo...@gmail.com> wrote:
> On Tue, Oct 8, 2013 at 3:44 PM, Carlos Martín Nieto <c...@elego.de> 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

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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to