Re: git push sends more objects than it needs to

From: Linus Torvalds <torvalds@osdl.org>
Date: Oct 31, 2005, 18:44 UTC
Message-ID: <Pine.LNX.4.64.0510311035310.27915@g5.osdl.org>
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:

...

Show 6 quoted lines

> 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