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

Re: warning: no common commits - slow pull

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 28, 2008, 17:52 UTC
Message-ID
<7vy795j7d2.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<alpine.LNX.1.00.0802281026030.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
Show 12 quoted lines
> Actually, I just realized something which should have been obvious: when 
> we reconnect, we get a list of the remote's refs, which we currently 
> discard immediately. We should actually pass this list to fetch_pack() if 
> we just reconnected, so that the client side always does the interaction 
> with the right idea of the server's refs, and discard it afterwards. The 
> fact that the user of transport_*() doesn't find out that the server 
> side's refs change in the middle of the life cycle and can't find out in 
> any way doesn't matter too much, so long as each actual connection is 
> internally consistant. (And the situation is no different from how it used 
> to be with git-fetch.sh: if you get a different mirror later, you may 
> discover that the server now doesn't have refs that it seemed to 
> advertize, but nothing weird happens.)

I think that would also be a valid way to solve this "stale idea of what the other side has" and can replace my weatherbaloon patch.

Another potential problem area is if find_common() does the right thing when it is called for the second time. I did not check if you clear COMMON, SEEN, COMPLETE etc. bits from the object database before initiating the second round, but if you didn't, I am afraid these bits left over from the primary transfer might interfere the common ancestor discovery during the second round.

Previous: Daniel BarkalowNext: Daniel Barkalow
Message 32 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.