On Sat, 26 Sep 2009, Jason Merrill wrote: > Incidentally, somewhat related to this issue, I've noticed that if I fetch a > branch which I don't currently have in my repository, and I have most of the > commits on that branch in my object store (or in an alternate repository) but > not the most recent commit, git fetch isn't smart enough to only grab the > commits I'm actually missing, it wants to fetch much more. > > I would expect that since the clone pulled down everything in the gcc.git > repository, I could then do > > git config remote.origin.fetch 'refs/remotes/*:refs/remotes/origin/*' > git fetch > > and have all the branches, not just the ones in refs/heads. But when I do > this git fetch wants to fetch some 500k redundant objects. Well... Assuming a fixed git using the patch I posted yesterday, my clone of gcc.git has 988941 objects. The source repository used for the clone has 1399551 objects. Of course the source repo has more objects because it has extra branches in the refs/remotes/ namespace that the clone didn't fetch. If you wish to also fetch those branches as you illustrated above then you'll get the difference i.e. 410610 additional objects. And even if the broken clone (before my patch) did pull everything from gcc.git, in the cloned repository those 410610 extra objects are considered as garbage because nothing actually reference them. So even if you decide to fetch the extra branches that the initial clone didn't pick up, or if you do reference that repository with "garbage" objects for another clone to which you want to add those extra branches, git has no way to know that it already had access to those objects locally and "ungarbage" them as they aren't referenced. Result is a useless fetch of 410610 objects that you already have, but that you weren't supposed to have in the first place. Nicolas -- 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