Thread (1 message) 1 message, 1 author, 2016-06-15

Re: Make "git clone" less of a deathly quiet experience

From: Eric W. Biederman <hidden>
Date: 2016-06-15 22:42:19

Andreas Ericsson [off-list ref] writes:
Keith Packard wrote:
quoted
On Sun, 2006-02-12 at 04:43 +0100, Andreas Ericsson wrote:
quoted
A weird oddity; Cloning is faster over rsync, day-to-day pulling is not.
Precisely. If the protocol could deliver existing packs instead of
unpacking and repacking them, then git would be as fast as rsync and I
wouldn't have to worry about supporting two protocols.
Caching features have been discussed, but that means the daemon needs to have
write-access to some directory within the repository. It would also work poorly
for projects that see very rapid development unless the cached pack-files can be
amended to. A sort of "create packs on demand". It shouldn't be too difficult,
really.
Actually for the clone case we don't need a writable directory for the
git-daemon. 

If we assume that a repository up for download is reasonably packed,
we can just lob all of the packs in the current repository, and then
pack the few remaining objects and send them.

I don't know how well multiple packs will work with the current git
protocol but it should be pretty natural, and the clone case is easy
detect as there are no heads in common.  Can that be detected quickly?

I don't have a patch but it feels like a pretty straight forward thing
to implement.

Eric
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help