git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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*
Previous: Johannes SchindelinNext: Junio C Hamano
Message 5 of 35 in “warning: no common commits - slow pull”
  1. Len BrownFeb 11, 2008
  2. Junio C HamanoFeb 11, 2008
  3. Daniel BarkalowFeb 17, 2008
  4. Johannes SchindelinFeb 17, 2008
  5. Daniel BarkalowFeb 17, 2008
  6. Junio C HamanoFeb 17, 2008
  7. Johannes SchindelinFeb 17, 2008
  8. Daniel BarkalowFeb 17, 2008
  9. Theodore TsoFeb 11, 2008
  10. Len BrownFeb 11, 2008
  11. Junio C HamanoFeb 11, 2008
  12. Theodore TsoFeb 11, 2008
  13. Len BrownFeb 15, 2008
  14. Johannes SchindelinFeb 16, 2008
  15. Florian WeimerFeb 25, 2008
  16. Daniel BarkalowFeb 25, 2008
  17. Len BrownFeb 26, 2008
  18. Nicolas PitreFeb 26, 2008
  19. Daniel BarkalowFeb 26, 2008
  20. Junio C HamanoFeb 27, 2008
  21. Junio C HamanoFeb 27, 2008
  22. Daniel BarkalowFeb 27, 2008
  23. Junio C HamanoFeb 27, 2008
  24. Daniel BarkalowFeb 27, 2008
  25. Shawn O. PearceFeb 28, 2008
  26. Shawn O. PearceFeb 28, 2008
  27. Jon LoeligerFeb 29, 2008
  28. Daniel BarkalowFeb 29, 2008
  29. Junio C HamanoFeb 28, 2008
  30. Daniel BarkalowFeb 28, 2008
  31. Always use the current connection's remote ref list in git protocolDaniel Barkalow, Feb 28, 2008
  32. Junio C HamanoFeb 28, 2008
  33. Daniel BarkalowFeb 28, 2008
  34. Florian WeimerFeb 11, 2008
  35. NixFeb 11, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.