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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html