Re: Continue git clone after interruption

From: =?VISCII?Q?Ren=E9_Scharfe?= <rene.scharfe@lsrfire.ath.cx>
Date: Aug 19, 2009, 22:23 UTC
Message-ID: <4A8C7B7A.6070700@lsrfire.ath.cx>
In-Reply-To: <alpine.LFD.2.00.0908191122020.6044@xanadu.home>

Nicolas Pitre schrieb:

Show 10 quoted lines

> 3) "git archive --remote=git://foo.bar/baz CLONE_HEAD" and store the 
>    result locally. Keep track of how many files are received, and how 
>    many bytes for the currently received file.
> 
> 4) if network connection is broken, loop back to (3) adding
>    --skip=${nr_files_received},${nr_bytes_in_curr_file_received} to
>    the git-archive argument list.  REmote server simply skips over 
>    specified number of files and bytes into the next file.
> 
> 5) Get content from remote commit object for CLONE_HEAD somehow. (?)

[...]

> - That probably would be a good idea to have a tgz format to 'git
>   archive' which might be simpler to deal with than the zip format.

Adding support for the tgz format would be useful anyway, I guess, and is easy to implement.

And adding support for cpio (and cpio.gz) and writing an extractor for it should be simpler than writing a tar extractor alone.

One needs to take a closer look at the limits of the chosen archive format (file name length, supported file types and attributes, etc.) to make sure any archive can be turned back into the same git tree.

The commit object could be sent as the first (fake) file of the archive.

You'd need a way to turn off the effect of the attributes export-subst and export-ignore.

Currently, convert_to_working_tree() is used on the contents of all files in an archive. You'd need a way to turn that off, too.

Adding a new format type is probably the easiest way to bundle the special requirements of the previous three paragraphs.

Ren�