Re: warning: no common commits - slow pull

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Feb 17, 2008, 20:41 UTC
Message-ID: <alpine.LNX.1.00.0802171437460.5816@iabervon.org>
In-Reply-To: <alpine.LSU.1.00.0802171925330.30505@racer.site>

On Sun, 17 Feb 2008, Johannes Schindelin wrote:

Show 24 quoted lines

> Hi,
> 
> On Sun, 17 Feb 2008, Junio C Hamano wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > On Sat, 16 Feb 2008, Daniel Barkalow wrote:
> > >
> > >> I wonder if the problem is that something isn't getting reinitialized 
> > >> for the second connection. It's not a separate invocation of 
> > >> fetch-pack, and I can't say for sure that it's sending the right info 
> > >> to the server when the statics in builtin-fetch-pack.c are left over 
> > >> from the earlier call. This would particularly explain the 
> > >> information that hitting ctrl-c and trying again fixes it.
> > >
> > > Oh, that should be it!  After all, the code in get_rev() in 
> > > builtin-fetch-pack.c marks commits as SEEN and COMMON and POPPED.
> > 
> > I seem to be slow today, but how does that explain that the problem is 
> > reported only by Len so far?
> 
> Hmm.  The code I was referencing is only in "next" so far, right?  And 
> AFAICT it only occurs when you are fetching something which autofetches 
> tags, right?

I think the code you referenced is quite old; the new thing is having it called twice in the same process, and that's also in "master" along with builtin-fetch, I think.

> But thinking about this again: do we reuse the connection also for 
> automatic tag fetching?  If not, my whole reasoning is wrong.

No, the way the protocol works, you can't request more stuff after you've received stuff on a connection, so we have to start a second one for that case.

	-Daniel
*This .sig left intentionally blank*