Re: git push sends more objects than it needs to

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