Re: warning: no common commits - slow pull

[Daniel Barkalow <barkalow@iabervon.org>]

On Sun, 17 Feb 2008, Johannes Schindelin wrote:

> Hi,
> 
> 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.
> 
> So I guess you'd need to set something like
> 
> 	struct commit_list *rev_list_orig;
> 	...
> 	rev_list_orig = rev_list;
> 
> before
> 
>         while ((sha1 = get_rev())) {
> 
> in the function find_common(), and then, after the while() loop, do 
> something like
> 
> 	while (rev_list_orig) {
> 		clear_commit_marks(rev_list->item,
> 			COMPLETE | COMMON | COMMON_REF | SEEN | POPPED);
> 		rev_list_orig = rev_list_orig->next;
> 	}
> 
> possibly free()ing the rev_lists in the process.

What's currently confusing me, which is probably why I haven't been able 
to reproduce the problem, is how we don't have the newly-received commits 
as still interesting. Clearly there's some way to end up with them 
either not being applicable or being already marked, but I'm not seeing 
it.

(There's a good change that we could fix the problem with your loop, but 
I'd like to have a test case to make sure it's fixed and stays fixed)

	-Daniel
*This .sig left intentionally blank*