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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.