Re: Why pack+unpack?
- From
Linus Torvalds <torvalds@osdl.org>
- Date
- Jul 26, 2005, 16:44 UTC
- Message-ID
- <Pine.LNX.4.58.0507260937460.19309@g5.osdl.org>
- In-Reply-To
- <42E5C677.2020403@pobox.com>
On Tue, 26 Jul 2005, Jeff Garzik wrote:
Show 10 quoted lines
> > > > 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