On Fri, 5 May 2006, Jakub Narebski wrote: > Linus Torvalds wrote: > > > So what you'd get is a _really_ cut down history that doesn't contain any > > commit history at all (just distinct "points in commit history time"), but > > that _does_ contain all the objects that the commits point to. > > So we would get 'skin-deep clone' rather than 'shallow' one? Well, it's really shallow, but perhaps more importantly, I think it should be really easy, and have totally unambiguous semantics. Never any question of how far back to go, and I think we already really do have all the support logic for doing it. Now, we don't actually expose the internal "no_walk" flag with a "--no-walk" command line argument parsing, but that's a one-liner. There's another approach that might be a bit friendlier, which is again to walk only the objects of the WANT/HAVE things, but then _do_ walk the history for just commit objects. Something close to what I think the http fetch thing does if you pass it "-c -t". That too shouldn't require too much extra complexity, and it would mean that "git log" at least works. Of course, that would require another slight difference to "rev-list.c", where we'd only recurse into trees of selected commit objects (ie we'd have to mark the HAVE/WANT commits specially, but it's not exactly complex either). Of course, the complexity of _both_ of these approaches is really in the fsck stage, and all the crud you need to then do other things with these pared-down repos. For example, do you allow cloning? And do you just automatically notice that you're cloning a shallow repo, and only do a shallow clone. Etc etc.. Linus - : 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