Re: [PATCH] send-pack: don't send a thin pack when the server doesn't support it

Duy Nguyen [off-list ref] writes:

On Tue, 2013-10-08 at 16:44 +0700, Duy Nguyen wrote:

On Tue, Oct 8, 2013 at 3:44 PM, Carlos Martín Nieto [off-list ref] wrote:

quoted

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

Oh, I'd never noticed that when looking though the network traffic. This seems like something that breaks the compatibility that git otherwise tries so hard to maintain. How did it happen that it's fine for the client to assume that the server supports thin packs?

receive-pack, perhaps a new extension "no-thin-pack" for those

servers? Alternatively, just run git push --no-thin (you'll need
f7c815c (push: respect --no-thin - 2013-08-12) though).

Yeah, I had an older version in my PATH and was bitten by that when
testing. Having --no-thin and the server's index-pack fail with missing
bases is quite worrying when you're the one who wrote most of the
server-side code.

Having to remember to run 'git push --no-thin' when pushing to one
particular project is pretty bad experience as a user and I was hoping
to avoid this with newer gits. We could advertise a "no-thin-pack"
extension if a patch to support that would be accepted into mainline
git.

Cheers,
   cmn