Duy Nguyen <pclo...@gmail.com> 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 <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
>
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
--
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
