Re: RFC: reverse history tree, for faster & background clones

From: Andres G. Aragoneses <knocte@gmail.com>
Date: Jun 12, 2015, 11:39 UTC
Message-ID: <mlegd8$t71$1@ger.gmane.org>
In-Reply-To: <1434108815.5381.3.camel@kaarsemaker.net>

On 12/06/15 13:33, Dennis Kaarsemaker wrote:

Show 6 quoted lines

> On vr, 2015-06-12 at 13:26 +0200, Andres G. Aragoneses wrote:
>
>> AFAIU git stores the contents of a repo as a sequence of patches in the
>> .git metadata folder.
>
> It does not, it stores full snapshots of files.

In bare repos too?

Show 5 quoted lines

>> 1. `git clone --depth 1` would be way faster, and without the need of
>> on-demand compressing of packfiles in the server side, correct me if I'm
>> wrong?
>
> You're wrong due to the misunderstanding of how git works :)

Thanks for pointing this out, do you mind giving me a link of some docs where I can correct my knowledge about this?

Show 11 quoted lines

>> 2. `git clone` would be able to allow a "fast operation, complete in the
>> background" mode that would allow you to download the first snapshot of
>> the repo very quickly, so that the user would be able to start working
>> on his working directory very quickly, while a "background job" keeps
>> retreiving the history data in the background.
>
> This could actually be a good thing, and can be emulated now with git
> clone --depth=1 and subsequent fetches in the background to deepen the
> history. I can see some value in clone doing this by itself, first doing
> a depth=1 fetch, then launching itself into the background, giving you a
> worktree to play with earlier.

You're right, didn't think about the feature that converts a --depth=1 repo to a normal one. Then a patch that would create a --progressive flag (for instance, didn't think of a better name yet) for the `clone` command would actually be trivial to create, I assume, because it would just use `depth=1` and then retrieve the rest of the history in the background, right?

Thanks