Re: Why pack+unpack?

On Tue, 26 Jul 2005, Jeff Garzik wrote:

quoted

Put another way: do you argue that X network transparency is a total waste
of time? You could certainly optimize X if you always made it be
local-machine only. Or you could make tons of special cases, and have X 
have separate code-paths for local clients and for remote clients, rather 
than just always opening a socket connection.

Poor example...   sure it opens a socket, but X certainly does have a 
special case local path (mit shm), and they're adding more for 3D due 
the massive amount of data involved in 3D.

.. and that's still a special case. Exactly like git does the "clone -l" 
special case.

Well, I'm not overly concerned, mostly curious.  The pack+unpack step 
(a) appears completely redundant and (b) is the step that takes the most 
time here, for local pulls, after the diffstat.

It's not actually redundant. Some of the _compression_ may be, and you 
could see if you prefer a smaller delta window (use "--window=0" to 
git-pack-objects to totally disable delta compression), but in general you 
can't actually just link the files over like with "git clone", because 
that would create total chaos and a real mess if the other end was packed.

So "git pull" actually needs to copy one object at a time in order to have 
sensible semantics together with "git repack". Now, you could make that 
"one object at a time" thing have its own special cases ("if it's packed, 
extract it as a unpacked object in the destination, if it's unpacked, just 
link it if you can"), but it would just be pretty ugly.

If it ever gets to be a real performance problem, we can certainly fix it,
but in the meantime I _much_ prefer having one single path. I dislike the
rsync (and the http) paths immensely already, but at least I don't have to
use them..

			Linus