Re: [PATCH 4/4] git-fetch-pack: Implement client part of the multi_ack extension

Hi,

On Tue, 25 Oct 2005, Junio C Hamano wrote:

> Alex Riesen <raa.lkml@gmail.com> writes:
> 
> > Johannes Schindelin, Sun, Oct 23, 2005 03:40:13 +0200:
> >> This patch concludes the series, which makes 
> >> git-fetch-pack/git-upload-pack negotiate a potentially better set of 
> >> common revs. It should make a difference when fetching from a repository 
> >> with a few branches.
> >
> > This broke git-pull for me (the local one):
> 
> Is this the same problem I fixed with this commit, which sits at
> the tip on the "master" branch?
> 
> commit 7efc8e43508b415e2540dbcb79521bde16c51e0c
> tree 6234aa4f7095054a137e030030f914dc6633f809
> parent 40a10462498bdd23d4e49f02867b8be50eb78704
> author Junio C Hamano <junkio@cox.net> 1130061738 -0700
> committer Junio C Hamano <junkio@cox.net> 1130192018 -0700
> 
>     upload-pack: fix thinko in common-commit finder code.
> 
>     The code to check if we have the object the other side has was bogus
>     (my fault).
> 
>     Signed-off-by: Junio C Hamano <junkio@cox.net>

It looks to me like it is not. This looks more like upload-pack speaks 
multi_ack, but fetch-pack does not, since it gets the "got ack .. 
continue" too late.

I'll send out a patch implementing a first version of my "nasty" 
fetch-pack tests in a few minutes. This test showed me my error.

Ciao,
Dscho

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