Re: [jgit-dev] Implementing shallow clones

[Matt Fischer <mattfischer84@xxxxxxxxx>]

>> This still has the disadvantage of walking the entire tree instead of
>> cutting off once the depth has been reached, but that doesn't seem
>> like it's the end of the world.  Do you feel like that's going to be a
>> big performance drain, or would it be ok?
>
> On small projects like JGit the difference isn't really that
> noticable between spinning the entire history through the topo
> generator, or spinning only a recent slice.
>
> But on bigger projects like the Linux kernel, its very noticable.
> Walking the commit chain just isn't fast enough, and never will be
> in Java.  Even if pack v4 comes around and magically improves things.
> Over time, its only going to get worse since its O(N), where N is
> the life of the project.  :-(
>
> ...
>
> Since shallow support is all about grabbing only a recent slice of
> the project, ideally we would be able to do it without needing to
> enumerate the complete history of the project.  :-\

Point taken.  At this point, I'm inclined to say screw it and just
implement DepthGenerator from scratch.  If I start with the code from
TopoSortGenerator, and modify it to only add parents if their depth is
low enough, I should basically get everything I need without a whole
lot of hassle.  I know copy-paste is evil and all, but
TopoSortGenerator is like fifty lines of fairly non-tricky code, so
maybe that wouldn't be TOO evil?  C Git does this with a little
one-off topological sort as well, so I don't think I'm entirely
off-base here.

--Matt