From: "V.Krishn" <vkrishn4@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Stalled git cloning and possible solutions
Date: Fri, 30 Aug 2013 03:58:33 +0530 [thread overview]
Message-ID: <201308300358.33272.vkrishn4@gmail.com> (raw)
In-Reply-To: <xmqqvc2o16pn.fsf@gitster.dls.corp.google.com>
On Friday, August 30, 2013 03:48:44 AM you wrote:
> "V.Krishn" <vkrishn4@gmail.com> writes:
> > On Friday, August 30, 2013 02:40:34 AM you wrote:
> >> V.Krishn wrote:
> >> > Quite sometimes when cloning a large repo stalls, hitting Ctrl+c
> >> > cleans what been downloaded, and process needs re-start.
> >> >
> >> > Is there a way to recover or continue from already downloaded files
> >> > during cloning ?
> >>
> >> No, sadly. The pack sent for a clone is generated dynamically, so
> >> there's no easy way to support the equivalent of an HTTP Range request
> >> to resume. Someone might implement an appropriate protocol extension
> >> to tackle this (e.g., peff's seed-with-clone.bundle hack) some day,
> >> but for now it doesn't exist.
> >
> > This is what I tried but then realized something more is needed:
> >
> > During stalled clone avoid Ctrl+c.
> > 1. Copy the content .i.e .git folder some other place.
> > 2. cd <new dir>
> > 3. git config fetch.unpackLimit 999999
> > 4. git config transfer.unpackLimit 999999
>
> These two steps will not help, as negotiation between the sender and
> the receiver is based on the commits that are known to be complete,
> and an earlier failed "fetch" will not (and should not) update refs
> on the receiver's side.
>
> >> What you *can* do today is create a bundle from the large repo
> >> somewhere with a reliable connection and then grab that using a
> >> resumable transport such as HTTP.
>
> Yes.
>
> Another possibility is, if the project being cloned has a tag (or a
> branch) that points at a commit back when it was smaller, do this
>
> git init x &&
> cd x &&
> git fetch $that_repository
> $that_tag:refs/tags/back_then_i_was_small
>
> to prime the object store of a temporary repository 'x' with a
> hopefully smaller transfer, and then use it as a "--reference"
> repository to the real clone.
Would be nice if,
1. the clone process downloaded all files in .git before the blobs or packing
process and added a lock file like .clone and then started the packing
process.
2. Any interrupt((ctrl+c) should not delete the already dowloaded files but on
re-clone process it should check .clone file and resume cloning.
3. Upon finishing cloning delete .clone file.
--
Regards.
V.Krishn
next prev parent reply other threads:[~2013-08-29 22:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-29 19:48 Stalled git cloning and possible solutions V.Krishn
2013-08-29 21:10 ` Jonathan Nieder
2013-08-29 21:35 ` V.Krishn
2013-08-29 22:18 ` Junio C Hamano
2013-08-29 22:28 ` V.Krishn [this message]
2013-09-04 1:06 ` V.Krishn
2013-08-30 12:17 ` Duy Nguyen
2013-08-30 12:41 ` Duy Nguyen
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=201308300358.33272.vkrishn4@gmail.com \
--to=vkrishn4@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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.