On Tue, 26 Jul 2005, Jeff Garzik wrote:
> > 
> > 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..

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to