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..
Linus
-
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
