From: Linus Torvalds Date: Mon, 31 Oct 2005 18:44:02 GMT Subject: Re: git push sends more objects than it needs to Message-ID: In-Reply-To: <20051031182355.GA7368@agluck-lia64.sc.intel.com> On Mon, 31 Oct 2005, Luck, Tony wrote: > > Finally, after making sure that release and test > branches still built with all the new stuff I did > a "git push" to update my kernel repo. I saw this: ... > Packing 10785 objects > Unpacking 10785 objects > > Now the "unpack" on kernel.org did the right thing and noticed > that over 9000 of the objects were already in the packfile. But > I wonder if it couldn't have been smarter and not sent them? It should have been smarter, but I suspect you got caught by the fact that kernel.org by default has git-0.99.8f on it, which has the old pre-multi_ack code to figure out what the common commit was. The pack-file contains over ten times as many objects, so you definitely didn't get all of them - but because there has been a lot of merges lately, and the common commit finder algorithm wasn't all that careful, you ended up getting many more objects than you really needed. Remember: the pack generation is not "exact" - it will often generate a few extra objects for any non-trivial case (for example, it fundamentally happens if there has been reverts: it won't realize that you had the older version of a file already). It just so happens that the old algorithm had some cases where it would decide on totally the wrong common commit, and re-send a _lot: more objects than it needs. I'm not sure multi-ack fixes it entirely either, but I think it makes it a lot less likely (but even with multi-ack, the "file revert" case still happens, so you should always expect that can get a _couple_ of unnecessary objects). Now, even the old stupid algorithm got the _easy_ cases obviously right, so people might have incorrectly gotten the idea that it was careful and exact, just because quite often it ends up being that in practice. Linus