Thread (8 messages) flat view 8 messages, 6 authors, 2016-08-13

Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha

From: Shawn O. Pearce <hidden>
Date: 2016-06-15 22:45:06

Petr Baudis [off-list ref] wrote:
On Tue, Aug 05, 2008 at 01:36:15AM +0200, Johannes Schindelin wrote:
quoted
And I absolutely share the puzzlement of Shawn why anybody would try to do 
their own thing in Java, instead of contributing to jgit.

Especially the fact that "JavaGit" seems to repeat the all-to-obvious 
error of Eclipse: to make a platform-independent library that depends on 
platform dependent components.
[Totally naive question coming with no knowledge of actual size of
current JGit's feature set:]

Wouldn't it make sense to have an ability to fall back on Git calls for
functionality that is not implemented natively yet? If you then don't
have Git available, you just don't get the functionality. What's the
catch?
Someone else asked to do this in JGit before (it was privately
off-list to Robin and myself).  Both of our responses were that we
were not that interested in having such dependencies in the main
JGit tree at this time, but that JGit is BSD and nothing would stop
them from forking our tree and trying it out.  If there really was
value there we would have to consider merging it back.

Nothing came of it as far as I know.

Someone recently ported git-blame into JGit, and it looks like they
did a good job, but it was a straight C->Java port.  Since JGit
is licensed under the BSD and builtin-blame.c is under the GPL we
couldn't accept it as-is.  That side project produced a lot more
results than anything else of late, but the GPL virual clause kicked
in and prevented direct inclusion.

-- 
Shawn.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help