If I were redoing git from scratch...

Linus Torvalds <torvaldsosdl.org> 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 majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html