{"thread":{"id":"43464","subject":"Re: egit/jgit wishlist","startedAt":"2006-12-04T17:28:36Z","lastAt":"2006-12-05T08:37:34Z","messageCount":10,"participants":["Shawn Pearce","Steven Grimm","Grzegorz Kulewski","Robin Rosenberg","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"296702","messageId":"20061204172836.GB6011@spearce.org","threadId":"43464","inReplyTo":null,"subject":"egit/jgit wishlist","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-04T17:28:36Z","receivedAt":"2006-12-04T17:28:36Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"I've started a wishlist:\n\n  http://git.or.cz/gitwiki/EclipsePluginWishlist\n\nMy idea is to work through these in the order shown on the page.\nI'm looking for comments from those who may be interested in this\nplugin, to see what they want/need to make it useful.\n\nThere's many months worth of work listed there, especially with\nthe amount of time that I have available for jgit/egit.  So I'm of\ncourse also hoping that others might see something there and try\nto implement it themselves.  :-)\n\n-- \n"},{"id":"295404","messageId":"457461BF.6080706@midwinter.com","threadId":"43464","inReplyTo":"20061204172836.GB6011@spearce.org","subject":"Re: egit/jgit wishlist","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2006-12-04T17:58:23Z","receivedAt":"2006-12-04T17:58:23Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"I am definitely looking forward to a usable Eclipse plugin! A few comments:\n\nMy usual git working style is to not switch branches with a dirty \nworking directory; I always commit to the current branch before \nswitching to a new one. I mention that because I assume it'll be easier \nto implement that workflow first; once you have commit capability, you \ncan do that style of branch switching (either preventing the switch or \ndoing an implicit commit when the working directory is dirty) without \nhaving to worry about merging.\n\nAnd finally, it would be swell -- but put it at the bottom of your \npriority list -- to have git-svn interoperability; sadly most of my git \nusage at the moment is in cloned svn repositories and it would be great \nif egit could do the right thing when the current git repo is cloned \nfrom svn. What \"the right thing\" is, exactly, is debatable, but I \nsuppose some kind of integration with the Subclipse plugin is one \npossibility (and if nothing else, that plugin probably has code that can \nbe reused.) I'd like to be able to update from and commit to the parent \nsvn repository.\n\n-Steve\n"},{"id":"294913","messageId":"20061204180553.GF6011@spearce.org","threadId":"43464","inReplyTo":"457461BF.6080706@midwinter.com","subject":"Re: egit/jgit wishlist","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-04T18:05:53Z","receivedAt":"2006-12-04T18:05:53Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Steven Grimm <koreth@midwinter.com> wrote:\n> My usual git working style is to not switch branches with a dirty \n> working directory; I always commit to the current branch before \n> switching to a new one. I mention that because I assume it'll be easier \n> to implement that workflow first; once you have commit capability, you \n> can do that style of branch switching (either preventing the switch or \n> doing an implicit commit when the working directory is dirty) without \n> having to worry about merging.\n\nIt is easier to code.  :-)\n\nBut users have come to expect the three-way merge during branch\nswitches.  I actually get ticked when it fails, because that is\nusually when I need it most.  Anyway, I also know a number of\nEclipse users who also use Git that would prefer it if the switch\nfails on a dirty working tree, as that usually just means they\nforgot to commit their changes first.\n \n> And finally, it would be swell -- but put it at the bottom of your \n> priority list -- to have git-svn interoperability; sadly most of my git \n> usage at the moment is in cloned svn repositories and it would be great \n> if egit could do the right thing when the current git repo is cloned \n> from svn. What \"the right thing\" is, exactly, is debatable, but I \n> suppose some kind of integration with the Subclipse plugin is one \n> possibility (and if nothing else, that plugin probably has code that can \n> be reused.) I'd like to be able to update from and commit to the parent \n> svn repository.\n\nSVN integration is probably out of scope for the plugin (at least\nright now) but I won't reject any reasonable patches!  (hint hint)\n:-)\n\n-- \n"},{"id":"297345","messageId":"Pine.LNX.4.63.0612041841280.14187@alpha.polcom.net","threadId":"43464","inReplyTo":"20061204172836.GB6011@spearce.org","subject":"Re: egit/jgit wishlist","fromName":"Grzegorz Kulewski","fromEmail":"kangur@polcom.net","sentAt":"2006-12-04T18:16:12Z","receivedAt":"2006-12-04T18:16:12Z","isPatch":false,"sender":{"key":"kangur@polcom.net","avatar":null},"body":"On Mon, 4 Dec 2006, Shawn Pearce wrote:\n> I've started a wishlist:\n>\n>  http://git.or.cz/gitwiki/EclipsePluginWishlist\n>\n> My idea is to work through these in the order shown on the page.\n> I'm looking for comments from those who may be interested in this\n> plugin, to see what they want/need to make it useful.\n>\n> There's many months worth of work listed there, especially with\n> the amount of time that I have available for jgit/egit.  So I'm of\n> course also hoping that others might see something there and try\n> to implement it themselves.  :-)\n\nHi,\n\nI am interested in seeing GIT support in Eclipse.\n\nI think that doing it in 100% pure Java is ok in long run but I wonder if \nyou couldn't make \"wrapper\" plugin for a start (that would call the real C \ngit for every operation) and make it usable (with full pure Java SWT UI \nsupport) and then try to implement feature by feature in pure Java (with \nconfig options telling what should be called by wrapper and what by pure \nimplementation)?\n\nThis way we could probably rather fast (basic versions of other GIT UIs \nwere created rather fast IIRC) have basic support for GIT (preferably \nwith GIT Java wrapper library for other projects) that would be usable for \nmost users and this way you could gain more interest in the project. Also \ntesting new pure implementation would be a lot easier (changing one line \nin config file to enable some pure Java feature and of course having an \noption to come back to wrapped version of this feature if new pure \nimplementation was wrong).\n\nWhat do you think about it?\n\n\nThanks,\n\nGrzegorz Kulewski\n"},{"id":"295093","messageId":"20061204182902.GG6011@spearce.org","threadId":"43464","inReplyTo":"Pine.LNX.4.63.0612041841280.14187@alpha.polcom.net","subject":"Re: egit/jgit wishlist","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-04T18:29:02Z","receivedAt":"2006-12-04T18:29:02Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Grzegorz Kulewski <kangur@polcom.net> wrote:\n> I think that doing it in 100% pure Java is ok in long run but I wonder if \n> you couldn't make \"wrapper\" plugin for a start (that would call the real C \n> git for every operation) and make it usable (with full pure Java SWT UI \n> support) and then try to implement feature by feature in pure Java (with \n> config options telling what should be called by wrapper and what by pure \n> implementation)?\n\nSeveral people have proposed doing exactly that, but thus far\nmyself and Robin Rosenburg have been the only two to step forward\nwith code.  I personally want to avoid calling external programs\nas much as possible here, and that means staying with a 100% pure\nJava implementation.  Hence the desire to not build a wrapper plugin.\n\nWe have the core repository reading and writing working.  We can\nwrite out trees.  We can create commits (we just lack UI for it).\nSo we're part of the way there...\n\n-- \n"},{"id":"298507","messageId":"457490EE.30606@midwinter.com","threadId":"43464","inReplyTo":"20061204182902.GG6011@spearce.org","subject":"Re: egit/jgit wishlist","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2006-12-04T21:19:42Z","receivedAt":"2006-12-04T21:19:42Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Shawn Pearce wrote:\n> I personally want to avoid calling external programs\n> as much as possible here, and that means staying with a 100% pure\n> Java implementation.  \n\nI think that's exactly the right decision.\n\nOne big advantage of doing it this way is that it will be reasonably \ncross-platform from the start. As soon as you start running external \nprograms, you introduce all the system dependencies of the Git \ncommand-line tools, especially acute if you're running some of the non-C \nporcelain commands (which will then require a working shell or Perl \nenvironment to be installed.)\n\nWith a wrapper-based implementation, the temptation would probably be \npretty great to just leave some stuff implemented as wrappers and not \nbother porting them, which would potentially kill portability. Insisting \non 100% pure Java means that particular temptation is never an issue.\n\n"},{"id":"298506","messageId":"Pine.LNX.4.63.0612042235270.14187@alpha.polcom.net","threadId":"43464","inReplyTo":"457490EE.30606@midwinter.com","subject":"Re: egit/jgit wishlist","fromName":"Grzegorz Kulewski","fromEmail":"kangur@polcom.net","sentAt":"2006-12-04T21:47:55Z","receivedAt":"2006-12-04T21:47:55Z","isPatch":false,"sender":{"key":"kangur@polcom.net","avatar":null},"body":"On Mon, 4 Dec 2006, Steven Grimm wrote:\n> Shawn Pearce wrote:\n>>  I personally want to avoid calling external programs\n>>  as much as possible here, and that means staying with a 100% pure\n>>  Java implementation. \n>\n> I think that's exactly the right decision.\n>\n> One big advantage of doing it this way is that it will be reasonably \n> cross-platform from the start. As soon as you start running external \n> programs, you introduce all the system dependencies of the Git command-line \n> tools, especially acute if you're running some of the non-C porcelain \n> commands (which will then require a working shell or Perl environment to be \n> installed.)\n>\n> With a wrapper-based implementation, the temptation would probably be pretty \n> great to just leave some stuff implemented as wrappers and not bother porting \n> them, which would potentially kill portability. Insisting on 100% pure Java \n> means that particular temptation is never an issue.\n\nBut it will be working (== end user usable) after many months not days.\n\nAnd please note that Java is not that portable as many people are \nsuggesting. Maybe it will change but currently I will bet C + bash + \nperl (+ python?) is more portable than Java. Java (J2SE) is officially \nsupported mainly under Windows, Solaris, Linux and maybe Mac. There are \nmore ports but unfortunatelly way too many of them are old, buggy, have \nnot full library implementations or something like that. Eclipse also \ncurrently works only under Windows, Linux and Mac.\n\nCan you name one system where Java (J2SE 1.4 or better 1.5) works (fully, \nnot sometimes) and where GIT does not work? Does Eclipse work there too \n(or will in say next year)?\n\nDon't get me wrong: I like Java, use it a lot and wish everything best for \nit but it is not the only or main anwser to every problem on this planet. \n:-) Good wrappers are often better at the begining than trying to do \neverything at once from scratch. And they are certainly faster to develop.\n\n\nThanks,\n\nGrzegorz Kulewski\n"},{"id":"297838","messageId":"200612042254.43224.robin.rosenberg.lists@dewire.com","threadId":"43464","inReplyTo":"Pine.LNX.4.63.0612041841280.14187@alpha.polcom.net","subject":"Re: egit/jgit wishlist","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-12-04T21:54:42Z","receivedAt":"2006-12-04T21:54:42Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"måndag 04 december 2006 19:16 skrev Grzegorz Kulewski:\n> Hi,\n>\n> I am interested in seeing GIT support in Eclipse.\n>\n> I think that doing it in 100% pure Java is ok in long run but I wonder if\n> you couldn't make \"wrapper\" plugin for a start (that would call the real C\n> git for every operation) and make it usable (with full pure Java SWT UI\n> support) and then try to implement feature by feature in pure Java (with\n> config options telling what should be called by wrapper and what by pure\n> implementation)?\n>\n> This way we could probably rather fast (basic versions of other GIT UIs\n> were created rather fast IIRC) have basic support for GIT (preferably\n> with GIT Java wrapper library for other projects) that would be usable for\n> most users and this way you could gain more interest in the project. Also\n> testing new pure implementation would be a lot easier (changing one line\n> in config file to enable some pure Java feature and of course having an\n> option to come back to wrapped version of this feature if new pure\n> implementation was wrong).\n>\n> What do you think about it?\n>\nCalling wrappers on top of C (JNI/exec), bash script, perl script etc etc is \nnot very easy or quick and requiring all dependencies on whatnot, makes \ninstallation of plugins very complicated. There would go a lot of work into \nworking with the wrappers, instead of creating a pure Java implementation. As \nShawn knows the Git internals very well, and the datastructures being \ndocumented, implementing a pure java version is the best thing, and maybe the \nsimplest, to do If an complete C library existed, maybe things would be \ndifferent. Most of the git storage access is already there.\n\nNote that many Git tools work with egit too allowing a smooth transition and \nthe implementation of feature by feature. I use clone, pull, push, Stacked \ngit, and the CVS tools today just fine in the same working area as egit. \nHaving a dependency on bash/perl/python etc, etc i EGIT would be counter \nproductive. I /could/ imaging a C-implementation of the index to make it \nfully interoperable with the git tools in the same working area, but that's \nabout it, because that would have to be C as java's portable API's does not \ninclude lstat.\n\nIt is possible though for those that wish to implement a separate plugin that \nprovides wrapper-implementation of certain features. To eclipse that would \njust be yet another plugin that provides some git-related feature.  Such \nplugins could use egit, jgit if necessary.\n\n"},{"id":"298125","messageId":"45749BD1.6070804@midwinter.com","threadId":"43464","inReplyTo":"Pine.LNX.4.63.0612042235270.14187@alpha.polcom.net","subject":"Re: egit/jgit wishlist","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2006-12-04T22:06:09Z","receivedAt":"2006-12-04T22:06:09Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Grzegorz Kulewski wrote:\n> Can you name one system where Java (J2SE 1.4 or better 1.5) works \n> (fully, not sometimes) and where GIT does not work? Does Eclipse work \n> there too (or will in say next year)?\n\nSure, I can name a pretty significant one: Windows. Eclipse, and Java in \ngeneral, runs fine under Windows and I doubt they'll drop support for it \nin the next year. Git doesn't run on Windows unless you're willing to \nfire up the Cygwin environment to run it, which is not acceptable to \nmany Windows developers (see the discussion about the Mozilla project; \nthat's not just my personal opinion.)\n\n-Steve\n"},{"id":"298257","messageId":"Pine.LNX.4.63.0612050922590.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43464","inReplyTo":"Pine.LNX.4.63.0612042235270.14187@alpha.polcom.net","subject":"Re: egit/jgit wishlist","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-05T08:37:34Z","receivedAt":"2006-12-05T08:37:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 4 Dec 2006, Grzegorz Kulewski wrote:\n\n> But it will be working (== end user usable) after many months not days.\n\nNot really. JNI is not that easy to get to work, you know? _Especially_ \nwith cygwin, where you have to transform pathnames from native to posix \nformat.\n\nIt is much work, for just a temporary solution.\n\n> And please note that Java is not that portable as many people are \n> suggesting.\n\nBut it is.\n\nThere are more official Java engines than just those from Sun. For \nexample, I worked on an SGI machine, where I did not have enough quota to \ninstall gcc and friends, but Java.\n\nAlso, now that it will be GPLed, you can be sure that even more platforms \nbecome supported.\n\nAnd the most important aspect of portability: You really can run the \ncompiled code anywhere. This is in stark contrast to C, C#, Perl, etc.\n\n> Maybe it will change but currently I will bet C + bash + perl (+ \n> python?) is more portable than Java.\n\nYou lost.\n\n> Java (J2SE) is officially supported mainly under Windows, Solaris, Linux \n> and maybe Mac. There are more ports but unfortunatelly way too many of \n> them are old, buggy, have not full library implementations or something \n> like that.\n\nAha. But you don't need them. For example, you do not need a full working \nCORBA library, or JDBC, or whatever. Java 1.1 should be sufficient (except \nfor that stupid mmap bug).\n\n> Eclipse also currently works only under Windows, Linux and Mac.\n\nThis a completely different beef. IBM, in its infinite wisdom, decided to \nscrap the platform independent Swing UI, and made its own (SWT). In C++. \nYes, you need to compile it for _every_ platform you want to run Eclipse \non. Brilliant.\n\n> Can you name one system where Java (J2SE 1.4 or better 1.5) works \n> (fully, not sometimes) and where GIT does not work?\n\nAs has been said, Windows. Oh, and some mobile phones. And some embedded \ndevices. Maybe even VMS.\n\nCiao,\nDscho\n"}]}