From: Vitaly <vitaly.berov@gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: git@vger.kernel.org, Shawn Pearce <spearce@spearce.org>,
Andreas Ericsson <ae@op5.se>,
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: git clone: very long "resolving deltas" phase
Date: Wed, 07 Apr 2010 12:14:36 +0400 [thread overview]
Message-ID: <4BBC3EEC.6010702@gmail.com> (raw)
In-Reply-To: <20100407080049.GA14041@LK-Perkele-V2.elisa-laajakaista.fi>
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".
P.S. Btw, how can I ask for a feature of incorporating hashes into
transport stream in trusted environments?
On 04/07/2010 12:00 PM, Ilari Liusvaara wrote:
> On Wed, Apr 07, 2010 at 09:54:29AM +0400, Vitaly Berov wrote:
>
>> I suspected the security reasons.
>>
>> Ok, we work in trusted environment. How can we turn this behavior off?
>>
>
> It can't be turned off. Protocol requires client to recompute hashes
> as they are not explicitly available in transport stream (must be inferred
> instead).
>
>
>>> This being said, you should never have to wait 6 hours for that phase to
>>> complete. It is typically a matter of minutes if not seconds.
>>>
> The reasons why it might take 6 hours (offhand from memory):
>
> - Extremely large repo
> - Very large files in repo pushing client into swap.
>
> -Ilari
>
>
next prev parent reply other threads:[~2010-04-07 8:15 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-06 14:18 git clone: very long "resolving deltas" phase Vitaly Berov
2010-04-06 15:01 ` Matthieu Moy
2010-04-06 15:28 ` Vitaly Berov
2010-04-06 15:29 ` Vitaly
2010-04-06 15:32 ` Andreas Ericsson
[not found] ` <q2mec874dac1004060850r5eaa41fak2ba9889d07794651@mail.gmail.com>
2010-04-06 15:56 ` Vitaly Berov
2010-04-06 21:09 ` Nicolas Pitre
2010-04-07 5:54 ` Vitaly Berov
2010-04-07 8:00 ` Ilari Liusvaara
2010-04-07 8:14 ` Vitaly [this message]
2010-04-07 9:00 ` Ilari Liusvaara
2010-04-07 9:37 ` Jakub Narebski
2010-04-07 14:20 ` Nicolas Pitre
2010-04-07 14:35 ` Vitaly
2010-04-07 14:55 ` Nicolas Pitre
2010-04-09 6:46 ` Vitaly Berov
2010-04-09 19:30 ` Nicolas Pitre
2010-04-10 6:32 ` Vitaly Berov
2010-04-07 14:08 ` Nicolas Pitre
2010-04-07 14:29 ` Sverre Rabbelier
2010-04-07 14:37 ` Vitaly
2010-04-07 5:55 ` Vitaly
2010-04-07 12:42 ` Nicolas Pitre
2010-04-06 21:05 ` Nicolas Pitre
2010-04-07 9:22 ` git clone: very long "resolving deltas" phase Marat Radchenko
2010-04-07 14:40 ` Nicolas Pitre
2010-04-06 21:01 ` git clone: very long "resolving deltas" phase Nicolas Pitre
2010-04-06 21:10 ` Nicolas Pitre
2010-04-07 5:57 ` Vitaly
2010-04-07 12:55 ` Nicolas Pitre
2010-04-09 6:50 ` Vitaly Berov
2010-04-09 8:13 ` Matthieu Moy
2010-04-09 19:18 ` Nicolas Pitre
2010-04-10 8:05 ` Vitaly Berov
2010-04-09 19:25 ` Nicolas Pitre
2010-04-10 7:58 ` Vitaly Berov
2010-04-10 13:25 ` Vitaly Berov
2010-04-11 0:50 ` Nicolas Pitre
2010-04-12 15:31 ` Vitaly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BBC3EEC.6010702@gmail.com \
--to=vitaly.berov@gmail.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=ilari.liusvaara@elisanet.fi \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).