On Thu, Mar 6, 2008 at 3:13 AM, Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> wrote: > Den Wednesday 05 March 2008 08.58.15 skrev Imran M Yousuf: > > > I would like to suggest 2 projects that I want to work as a developer > > (and/or mentor): > > > > 1. GIT SCM Plugin for NetBeans (GPLv2 with CPE, same as NetBeans) > > The aim of the plugin is to integrate GIT with NetBeans using JNI so > > that any change in the implementation of GIT does not effect the SCM > > plugins way of work. > > Language: Java > > Goal: Make GIT available from IDE for NetBeans users and use GIT using > > Java Native Interfaces > > 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. I am honoured and would be grateful for your support. > > 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. I was taking a look at the Mercurial VCS Plugin for NetBeans and I think GIT's one will be similar. Using jGit would be great; Do you have any plans to have a Maven version of jGit so that it could be used from any Maven project? Another question is - Is jGit dependent on any Eclipse API (dont even bother if the answer is no)? Can we have a separate repo for jGit so that it is maintained independently on eGit? > > 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 > -- Imran M Yousuf Entrepreneur & Software Engineer Smart IT Engineering Dhaka, Bangladesh Email: imran@xxxxxxxxxxxxxxxxxxxxxx Mobile: +880-1711402557 -- 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
