Re: git clone: very long "resolving deltas" phase

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 7 Apr 2010, Vitaly wrote:

> Too bad..
> Yes, we really have a very large repo with binary files.
> 
> So, as far as I understand, the fastest way is to use rsync or smth like this
> instead of "git clone".

You should still be able to use 'git clone' with a rsync:// style URL.

> P.S. Btw, how can I ask for a feature of incorporating hashes into transport
> stream in trusted environments?

As I'm trying to make you understand repeatedly now, this shouldn't be 
needed.  A real fix for the bad behavior would be in order before 
papering over it.

If the large binary blobs are the source of the clone problem, then they 
will cause the same problems with other commands such as 'git diff' or 
even 'git checkout' later on.  So that "feature" you're asking for is 
misguided.

What you might try on your client machines is this:

	git config --global core.deltaBaseCacheLimit 256m

before doing a clone.


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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]