Re: egit/jgit wishlist

From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Date: Dec 4, 2006, 21:54 UTC
Message-ID: <200612042254.43224.robin.rosenberg.lists@dewire.com>
In-Reply-To: <Pine.LNX.4.63.0612041841280.14187@alpha.polcom.net>

måndag 04 december 2006 19:16 skrev Grzegorz Kulewski:

Show 22 quoted lines

> Hi,
>
> I am interested in seeing GIT support in Eclipse.
>
> I think that doing it in 100% pure Java is ok in long run but I wonder if
> you couldn't make "wrapper" plugin for a start (that would call the real C
> git for every operation) and make it usable (with full pure Java SWT UI
> support) and then try to implement feature by feature in pure Java (with
> config options telling what should be called by wrapper and what by pure
> implementation)?
>
> This way we could probably rather fast (basic versions of other GIT UIs
> were created rather fast IIRC) have basic support for GIT (preferably
> with GIT Java wrapper library for other projects) that would be usable for
> most users and this way you could gain more interest in the project. Also
> testing new pure implementation would be a lot easier (changing one line
> in config file to enable some pure Java feature and of course having an
> option to come back to wrapped version of this feature if new pure
> implementation was wrong).
>
> What do you think about it?
>

Calling wrappers on top of C (JNI/exec), bash script, perl script etc etc is not very easy or quick and requiring all dependencies on whatnot, makes installation of plugins very complicated. There would go a lot of work into working with the wrappers, instead of creating a pure Java implementation. As Shawn knows the Git internals very well, and the datastructures being documented, implementing a pure java version is the best thing, and maybe the simplest, to do If an complete C library existed, maybe things would be different. Most of the git storage access is already there.

Note that many Git tools work with egit too allowing a smooth transition and the implementation of feature by feature. I use clone, pull, push, Stacked git, and the CVS tools today just fine in the same working area as egit. Having a dependency on bash/perl/python etc, etc i EGIT would be counter productive. I /could/ imaging a C-implementation of the index to make it fully interoperable with the git tools in the same working area, but that's about it, because that would have to be C as java's portable API's does not include lstat.

It is possible though for those that wish to implement a separate plugin that provides wrapper-implementation of certain features. To eclipse that would just be yet another plugin that provides some git-related feature. Such plugins could use egit, jgit if necessary.