Linus Torvalds <torvalds@xxxxxxxx> wrote: > or for somebody who re-implements git in Java (where > performance isn't going to be the major issue anyway, and you probably do > "small" things like "commit" and "diff", and never do full-database things > like "git repack"), _then_ you can happily look at having something > fancier. Right now, it's too easy to just look at cumbersome interfaces, > and forget about the fact that those interfaces is sometimes what allows > us to practically do some things in the first place. Yes and no. :-) As the only person here who has hacked on some of Git and also reimplemented the core on disk data structures in Java I can say I mostly agree with Linus. Abstractions like the repository (to allow different GIT_DIRs to be used in the same process) isn't really a big deal and is not a large impact on performance. They could be implemented in the current C core. But trying to abstractly represent an object in Java the same way that it is represented in Git costs a huge amount of memory. Java is at least 16 bytes of overhead per object, before you get to store anything in it. Translation: Linus is right, doing a real implementation of "git repack" in Java is nuts. It would barely be able to handle git.git, let alone linux.git or mozilla.git. -- Shawn. - 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