egit/jgit wishlist

egit/jgit wishlist

[Shawn Pearce]

I've started a wishlist:

  http://git.or.cz/gitwiki/EclipsePluginWishlist

My idea is to work through these in the order shown on the page.
I'm looking for comments from those who may be interested in this
plugin, to see what they want/need to make it useful.

There's many months worth of work listed there, especially with
the amount of time that I have available for jgit/egit.  So I'm of
course also hoping that others might see something there and try
to implement it themselves.  :-)

-- 

Re: egit/jgit wishlist

[Steven Grimm]

I am definitely looking forward to a usable Eclipse plugin! A few comments:

My usual git working style is to not switch branches with a dirty 
working directory; I always commit to the current branch before 
switching to a new one. I mention that because I assume it'll be easier 
to implement that workflow first; once you have commit capability, you 
can do that style of branch switching (either preventing the switch or 
doing an implicit commit when the working directory is dirty) without 
having to worry about merging.

And finally, it would be swell -- but put it at the bottom of your 
priority list -- to have git-svn interoperability; sadly most of my git 
usage at the moment is in cloned svn repositories and it would be great 
if egit could do the right thing when the current git repo is cloned 
from svn. What "the right thing" is, exactly, is debatable, but I 
suppose some kind of integration with the Subclipse plugin is one 
possibility (and if nothing else, that plugin probably has code that can 
be reused.) I'd like to be able to update from and commit to the parent 
svn repository.

-Steve

Re: egit/jgit wishlist

[Shawn Pearce]

Steven Grimm <koreth@midwinter.com> wrote:
> My usual git working style is to not switch branches with a dirty 
> working directory; I always commit to the current branch before 
> switching to a new one. I mention that because I assume it'll be easier 
> to implement that workflow first; once you have commit capability, you 
> can do that style of branch switching (either preventing the switch or 
> doing an implicit commit when the working directory is dirty) without 
> having to worry about merging.

It is easier to code.  :-)

But users have come to expect the three-way merge during branch
switches.  I actually get ticked when it fails, because that is
usually when I need it most.  Anyway, I also know a number of
Eclipse users who also use Git that would prefer it if the switch
fails on a dirty working tree, as that usually just means they
forgot to commit their changes first.
 
> And finally, it would be swell -- but put it at the bottom of your 
> priority list -- to have git-svn interoperability; sadly most of my git 
> usage at the moment is in cloned svn repositories and it would be great 
> if egit could do the right thing when the current git repo is cloned 
> from svn. What "the right thing" is, exactly, is debatable, but I 
> suppose some kind of integration with the Subclipse plugin is one 
> possibility (and if nothing else, that plugin probably has code that can 
> be reused.) I'd like to be able to update from and commit to the parent 
> svn repository.

SVN integration is probably out of scope for the plugin (at least
right now) but I won't reject any reasonable patches!  (hint hint)
:-)

-- 

Re: egit/jgit wishlist

[Grzegorz Kulewski]

On Mon, 4 Dec 2006, Shawn Pearce wrote:
> I've started a wishlist:
>
>  http://git.or.cz/gitwiki/EclipsePluginWishlist
>
> My idea is to work through these in the order shown on the page.
> I'm looking for comments from those who may be interested in this
> plugin, to see what they want/need to make it useful.
>
> There's many months worth of work listed there, especially with
> the amount of time that I have available for jgit/egit.  So I'm of
> course also hoping that others might see something there and try
> to implement it themselves.  :-)

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?


Thanks,

Grzegorz Kulewski

Re: egit/jgit wishlist

[Shawn Pearce]

Grzegorz Kulewski <kangur@polcom.net> wrote:
> 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)?

Several people have proposed doing exactly that, but thus far
myself and Robin Rosenburg have been the only two to step forward
with code.  I personally want to avoid calling external programs
as much as possible here, and that means staying with a 100% pure
Java implementation.  Hence the desire to not build a wrapper plugin.

We have the core repository reading and writing working.  We can
write out trees.  We can create commits (we just lack UI for it).
So we're part of the way there...

-- 

Re: egit/jgit wishlist

[Steven Grimm]

Shawn Pearce wrote:
> I personally want to avoid calling external programs
> as much as possible here, and that means staying with a 100% pure
> Java implementation.  

I think that's exactly the right decision.

One big advantage of doing it this way is that it will be reasonably 
cross-platform from the start. As soon as you start running external 
programs, you introduce all the system dependencies of the Git 
command-line tools, especially acute if you're running some of the non-C 
porcelain commands (which will then require a working shell or Perl 
environment to be installed.)

With a wrapper-based implementation, the temptation would probably be 
pretty great to just leave some stuff implemented as wrappers and not 
bother porting them, which would potentially kill portability. Insisting 
on 100% pure Java means that particular temptation is never an issue.

Re: egit/jgit wishlist

[Grzegorz Kulewski]

On Mon, 4 Dec 2006, Steven Grimm wrote:
> Shawn Pearce wrote:
>>  I personally want to avoid calling external programs
>>  as much as possible here, and that means staying with a 100% pure
>>  Java implementation. 
>
> I think that's exactly the right decision.
>
> One big advantage of doing it this way is that it will be reasonably 
> cross-platform from the start. As soon as you start running external 
> programs, you introduce all the system dependencies of the Git command-line 
> tools, especially acute if you're running some of the non-C porcelain 
> commands (which will then require a working shell or Perl environment to be 
> installed.)
>
> With a wrapper-based implementation, the temptation would probably be pretty 
> great to just leave some stuff implemented as wrappers and not bother porting 
> them, which would potentially kill portability. Insisting on 100% pure Java 
> means that particular temptation is never an issue.

But it will be working (== end user usable) after many months not days.

And please note that Java is not that portable as many people are 
suggesting. Maybe it will change but currently I will bet C + bash + 
perl (+ python?) is more portable than Java. Java (J2SE) is officially 
supported mainly under Windows, Solaris, Linux and maybe Mac. There are 
more ports but unfortunatelly way too many of them are old, buggy, have 
not full library implementations or something like that. Eclipse also 
currently works only under Windows, Linux and Mac.

Can you name one system where Java (J2SE 1.4 or better 1.5) works (fully, 
not sometimes) and where GIT does not work? Does Eclipse work there too 
(or will in say next year)?

Don't get me wrong: I like Java, use it a lot and wish everything best for 
it but it is not the only or main anwser to every problem on this planet. 
:-) Good wrappers are often better at the begining than trying to do 
everything at once from scratch. And they are certainly faster to develop.


Thanks,

Grzegorz Kulewski

Re: egit/jgit wishlist

[Robin Rosenberg]

måndag 04 december 2006 19:16 skrev Grzegorz Kulewski:
> 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.

Re: egit/jgit wishlist

[Steven Grimm]

Grzegorz Kulewski wrote:
> Can you name one system where Java (J2SE 1.4 or better 1.5) works 
> (fully, not sometimes) and where GIT does not work? Does Eclipse work 
> there too (or will in say next year)?

Sure, I can name a pretty significant one: Windows. Eclipse, and Java in 
general, runs fine under Windows and I doubt they'll drop support for it 
in the next year. Git doesn't run on Windows unless you're willing to 
fire up the Cygwin environment to run it, which is not acceptable to 
many Windows developers (see the discussion about the Mozilla project; 
that's not just my personal opinion.)

-Steve

Re: egit/jgit wishlist

[Johannes Schindelin]

Hi,

On Mon, 4 Dec 2006, Grzegorz Kulewski wrote:

> But it will be working (== end user usable) after many months not days.

Not really. JNI is not that easy to get to work, you know? _Especially_ 
with cygwin, where you have to transform pathnames from native to posix 
format.

It is much work, for just a temporary solution.

> And please note that Java is not that portable as many people are 
> suggesting.

But it is.

There are more official Java engines than just those from Sun. For 
example, I worked on an SGI machine, where I did not have enough quota to 
install gcc and friends, but Java.

Also, now that it will be GPLed, you can be sure that even more platforms 
become supported.

And the most important aspect of portability: You really can run the 
compiled code anywhere. This is in stark contrast to C, C#, Perl, etc.

> Maybe it will change but currently I will bet C + bash + perl (+ 
> python?) is more portable than Java.

You lost.

> Java (J2SE) is officially supported mainly under Windows, Solaris, Linux 
> and maybe Mac. There are more ports but unfortunatelly way too many of 
> them are old, buggy, have not full library implementations or something 
> like that.

Aha. But you don't need them. For example, you do not need a full working 
CORBA library, or JDBC, or whatever. Java 1.1 should be sufficient (except 
for that stupid mmap bug).

> Eclipse also currently works only under Windows, Linux and Mac.

This a completely different beef. IBM, in its infinite wisdom, decided to 
scrap the platform independent Swing UI, and made its own (SWT). In C++. 
Yes, you need to compile it for _every_ platform you want to run Eclipse 
on. Brilliant.

> Can you name one system where Java (J2SE 1.4 or better 1.5) works 
> (fully, not sometimes) and where GIT does not work?

As has been said, Windows. Oh, and some mobile phones. And some embedded 
devices. Maybe even VMS.

Ciao,
Dscho