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*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
