Re: warning: no common commits - slow pull
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Feb 17, 2008, 17:46 UTC
- Message-ID
- <alpine.LNX.1.00.0802171236560.5496@iabervon.org>
- In-Reply-To
- <alpine.LSU.1.00.0802171449230.30505@racer.site>
On Sun, 17 Feb 2008, Johannes Schindelin wrote:
Show 34 quoted lines
> 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*