Den Wednesday 05 March 2008 08.58.15 skrev Imran M Yousuf:
As the current acting maintainer or egit/jgit I would not mind cooperating
with making it available to Netbeans, J2EE and command line interface or
whatever.
You can make a plugin for Netbeans today that will do the basic like walking
the history, finding out what to commit, commit, switch/create/reset
branches, decorations based on jgit and you wouldn't need to change a thing
in jgit. There might be things you *want* to change, but that's another story
and applied to the continued development for the Eclipse plugin too. Even
the license might be changed.
You will find support in jgit for this today. Cloning over git and ssh real
soon. I'm clensing the oopses from the history right now. (bless rebase -i
and git-gui).
There are no dependencies on Eclipse and I do not plan on introducing any.
Jgit and Egit live in the same repo at the moment simply because there are
no other users of egit so far.
There might be some operations that might be harder to do well in Java. For
those exec'ing might be the solution, I'm thinking repack, but then I haven't
tried it yet. In general jgit is almost as fast as git and probably
outperforms git on windows as git there doesn't use memory mapped I/O for
packs (something I'd expect someone or even me to fix soon). For JNI'ed
operations the complexity is just horrible and even when possible, there is
a lot of overhead for JNI itselt, conversion from UTF-16 to somehing
eightbitish and back. On windows there's even yet another layer of
eight-bitish to UTF-16 and back in the Win32 API. Jgit also uses memory
mapped I/O on all platforms that support it for pack reading.
If someone *did* make a fully reentrant libgit, I'd be inclined to balance my
opinions differently.
-- robin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html