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

Re: warning: no common commits - slow pull

From
Theodore Tso <tytso@mit.edu>
Date
Feb 11, 2008, 01:53 UTC
Message-ID
<20080211015342.GA26205@mit.edu>
In-Reply-To
<200802102007.38838.lenb@kernel.org>
On Sun, Feb 10, 2008 at 08:07:38PM -0500, Len Brown wrote:
Show 20 quoted lines
> A couple of hours ago I pulled my reference copy of Linux tree,
> which brought the tip here:
> 
> commit 7cf712db6087342e5e7e259d3883a7b5ac3212d1
> Merge: 58a14ee... 30ddb15...
> Author: Linus Torvalds <torvalds@woody.linux-foundation.org>
> Date:   Sun Feb 10 12:03:57 2008 -0800
> 
>     Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
> 
> Then, 10 minutes ago I did a pull to bring the head here:
> 
> commit 19af35546de68c872dcb687613e0902a602cb20e
> Author: Linus Torvalds <torvalds@woody.linux-foundation.org>
> Date:   Sun Feb 10 14:18:14 2008 -0800
> 
>     Linux 2.6.25-rc1
> 
> But this second pull seems to have re-downloaded 172MB,
> when it should have only needed the last few commits.

Yeah, I have this problem very often when I push to the ext4 tree on master.kernel.org. Apparently the push/pull logic isn't smart about objects are found via objects/info/alterntaes, so it will needlessly transfer objects that it doesn't need to.

What I do to deal with this problem is I'll manually log into master.kernel.org, and then use the command "git-update-ref refs/heads/origin 19af35546de68c872dcb687613e0902a602cb20e", and then go back and do the push/pull. Once there is a head which points to the latest from Linus, then the push/pull logic is smart and will only download the few commitments that aren't in the local git repository and aren't found in a shared repository.

Annoying, but as long as you have shell access on the machine with the destination repository, you can work around it.

					- Ted
Previous: Daniel BarkalowNext: Len Brown
Message 9 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.