Re: git-clone and unreliable links?

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Nov 9, 2012, 16:35 UTC
Message-ID: <CAMK1S_jK2w2RYWbFmqnwJdSVmFnacGPLbEGzUWOLukqK_=HEbA@mail.gmail.com>
In-Reply-To: <CAJo=hJtJPnQFjvz8AAQjf5Rze-_99vF_tYi9CqJ7fiW245Dv1w@mail.gmail.com>

On Wed, Nov 7, 2012 at 9:24 PM, Shawn Pearce <spearce@spearce.org> wrote:

Show 19 quoted lines

> On Wed, Nov 7, 2012 at 7:35 AM, Josef Wolf <jw@raven.inka.de> wrote:
>> When using git-clone over an unreliable link (say, UMTS) and the network goes
>> down, git-clone deletes everything what was downloaded. When the network goes
>> up again and you restart git-clone, it has to start over from the
>> beginning. Then, eventually, the network goes down again, and everything is
>> deleted again.
>>
>> Is there a way to omit the deleting step, so the second invocation would start
>> where the first invocation was interrupted?
>
> No, because a clone is not resumable.
>
> The best way to obtain a repository over an unstable link is to ask
> the repository owner to make a bundle file with `git bundle create
> --heads --tags` and serve the file using standard HTTP or rsync, which
> are resumable protocols. After you download the file, you can clone or
> fetch from the bundle to initialize your local repository, and then
> run git fetch to incrementally update to anything that is more recent
> than the bundle's creation.

If the server is running gitolite, the admin can set it up so that a bundle file is automatically created as needed (including "don't do it more than once per <duration>" logic), and serve it up over rsync using the same ssh credentials as for access to the repo itself.

However, this is not particularly useful for systems with git://, although it could certainly be *adapted* for http access.

[Documentation is inline, in src/commands/rsync, for people who wish to know.]

-- 
Sitaram