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

[Dennis Kaarsemaker <dennis@kaarsemaker.net>]

On vr, 2015-06-12 at 13:39 +0200, Andres G. Aragoneses wrote:
> On 12/06/15 13:33, Dennis Kaarsemaker wrote:
> > 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?

Yes. A bare repo is nothing more than the .git dir of a non-bare repo
with the core.bare variable set to True :)

> >> 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?

http://git-scm.com/book/en/v2/Git-Internals-Git-Objects should help.

> >> 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?

A naive implementation that does just clone --depth=1 and then fetch
--unshallow would probably not be too hard, no. But whether that would
be the 'right' way of implementing it, I wouldn't know.

-- 
Dennis Kaarsemaker
http://www.kaarsemaker.net