{"thread":{"id":"14833","subject":"Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha","startedAt":"2008-08-04T16:48:02Z","lastAt":"2008-08-05T01:46:47Z","messageCount":8,"participants":["Shawn O. Pearce","Johannes Schindelin","A Large Angry SCM","Petr Baudis","Pieter de Bie","James Linder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"299057","messageId":"5dfc0b810808040948x6cd1f29fhaf2bf85a09cfd404@mail.gmail.com","threadId":"14833","inReplyTo":null,"subject":"NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha","fromName":"James Linder","fromEmail":"james.h.linder@gmail.com","sentAt":"2008-08-04T16:48:02Z","receivedAt":"2008-08-04T16:48:02Z","isPatch":false,"sender":{"key":"james.h.linder@gmail.com","avatar":null},"body":"Hello Git Developers and Users,\n\nThis summer, New York University held a class called Open Source\nProgramming. One of the projects to come out of the class is JavaGit,\nan API providing access to git repositories for Java applications.\nToday the JavaGit team has released version 0.1.0 Alpha of the JavaGit\nAPI. The announcement is listed below.\n\nWe are looking forward to continuing the project and grow the project\nand welcome new volunteers. So if the project sounds interesting,\ncheck it out and let us know what you think.\n\nRegards,\n\nThe JavaGit Team\n\n------------------------------------------------------------\nJavaGit Releases Version 0.1.0 Alpha - August 4, 2008\n\nThe JavaGit team is pleased to announce the release of JavaGit version\n0.1.0 alpha, an API providing access to git repositories from Java\nprograms. The goal of JavaGit is to bring the power of git to the Java\ndeveloper as an API that is intuitive for developers new to git and\ndevelopers who are veteran git users.\n\nJavaGit is engineered to provide the developer with access to the raw\ngit commands through a command API as well as an object API designed\nto represent the .git repository, the working tree and other, familiar\ngit concepts. JavaGit uses the git binaries installed on the host\nmachine to provide git functionality and has been designed to easily\naccommodate additional methods of access to git repositories.\n\nJavaGit is released as open source software under the GNU LGPL license.\n\nFor additional information on the JavaGit project, please visit:\n\n http://www.javagit.com\n"},{"id":"86214","messageId":"20080804175403.GG27666@spearce.org","threadId":"14833","inReplyTo":"5dfc0b810808040948x6cd1f29fhaf2bf85a09cfd404@mail.gmail.com","subject":"Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-04T17:54:03Z","receivedAt":"2008-08-04T17:54:03Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"James Linder wrote:\n> This summer, New York University held a class called Open Source\n> Programming. One of the projects to come out of the class is JavaGit,\n> an API providing access to git repositories for Java applications.\n> Today the JavaGit team has released version 0.1.0 Alpha of the JavaGit\n> API. The announcement is listed below.\n\nThis is interesting work. Competition is good, but I think many\nof us, especially those involved in egit and jgit, would wonder\nwhy a new project was started instead of contributing to one that\nalready is established.\n \n> JavaGit is engineered to provide the developer with access to the raw\n> git commands through a command API as well as an object API designed\n> to represent the .git repository, the working tree and other, familiar\n> git concepts. JavaGit uses the git binaries installed on the host\n> machine to provide git functionality and has been designed to easily\n> accommodate additional methods of access to git repositories.\n\nOne of the primary drivers behind why jgit does not call out to C\nGit is to remove the need to install Git binaries on the system.\nSome of the Eclipse IDE distributions won't bundle a plugin that\ndepends upon GPL executables, and hence won't bundle an Eclipse\nGit plugin like that.\n\nAnother is performance. Although jgit is written in Java it can\nbeat the performance of C Git for certain operations due to its\nability to avoid fork+exec. I've actually had a few times where\nwriting something in Java against jgit turned out to be easier\nand faster than writing it in Perl/Python/Tcl/shell against the C\nGit binary, because I was able to avoid the fork+exec overheads.\nAlthough I suspect C Git would have performed a lot better if we\nhad proper library bindings into say Perl.\n\n\nI would like to correct one statement in both the JavaGit and\ngitclipse FAQ's:\n\n>From http://gitclipse.sourceforge.net/docs/faq.php:\n> How is this different from egit/jgit?\n> \n> Who/What?!\n\nSeriously? egit and jgit is a 2.5 year old project that has a\nGoogle Summer of Code student working on it this summer, and is\nseeing 20+ patch clusters at least once a month on this list.\nYou cannot really claim we aren't visible in the Git community.\n\n> No seriously, we have a lot of respect for the egit/jgit project\n> they have done a lot of good work. There are several things that\n> differentiate us.\n> \n> * egit/jgit are being developed together as one project\n> whereas our API is developed seperately by a different team\n> of developers. This allows our development team to focus our\n> development efforts on our plug-in and not get hung up on\n> API issues.\n\nThey are only in the same repository because they started out that\nway for convience when it comes to committing. jgit is completely\nseperate from egit and comes with a build process to compile a\nstand-alone command line interface based entirely on jgit.\n\nThe _only_ reason they haven't been split into two different Git\nrepositories is because we just haven't wanted to slow down our\ndevelopment for such a trivial administrative item.\n\nIf this really was something that was holding back the adoption\nof and contribution to jgit, we'd split it tomorrow, and suffer\nthe pain of needing to segment development branches.\n\n>From http://javagit.sourceforge.net/faq.php:\n> How is JavaGit different from Jgit/Egit?\n> \n> Who/What?\n> \n> No. But seriously now. JavaGit was conceived of as a complementary\n> project to the GitClipse projct, an Eclipse plugin to provide git\n> support. It was a logical choice for us to split the project into\n> the user oriented project, Gitclipse, and the developer oriented\n> project, JavaGit. Since the projects are separate, the JavaGit\n> project is free to concentrate on providing a top-notch library/API\n> for use in other applications.\n\nOddly enough this is how jgit and egit came along. I wanted to\nbuild an Eclipse plugin, but also wanted to make sure that the\nmajority of the implementation code was not tied to the Eclipse\nplatform APIs or to the UI so that we could reuse it on other\nIDEs (e.g. NetBeans), or on build tools (Maven, Ant, ...), or\nfor a command line based tool (e.g. jgit's .pgm package).\n\n> Jgit/Egit, on the other hand, appear to be tightly integrated with\n> Jgit primarily supporting Egit.\n\nThat's not really true. jgit has two major users: egit and its\nrelated jgit.pgm package (which offers a CLI). Its sad that there\nare not yet more jgit users. But jgit itself has no dependency on\negit, and is not tightly integrated with it.\n\nI could claim that gitclipse and javagit are tightly integrated\nbecause they are both hosted on SVN on sourceforge.net. That's\nabout the same level of \"tightly integrated\" that jgit and egit are.\n\n> Another difference between JavaGit and Jgit/Egit is that the JavaGit\n> team wanted to quickly implement access to git repositories. This\n> goal lead us to start by forking to git itself to provide git\n> functionality. Knowing that this may be a short-term solution,\n> we built JavaGit so that we can easily replace the command line\n> interface (CLI) functionality with JNI, pure Java, or some other\n> implementation in the future. Jgit/Egit only provides a pure Java\n> implementation.\n\nMaybe I'm missing something, but I think egit has more features\navailable in its UI, and all of those are implemented directly\nby jgit. We even have a graphical history viewer with renderers\nbuilt in both AWT and SWT, and the SWT one is available in Eclipse.\nSo I'm not sure I follow this argument that JavaGit enabled the\nteam to produce an Eclipse plugin that offers more features, quicker.\n\n-- \nShawn.\n"},{"id":"86224","messageId":"alpine.DEB.1.00.0808050127510.9611@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"14833","inReplyTo":"20080804175403.GG27666@spearce.org","subject":"Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-08-04T23:36:15Z","receivedAt":"2008-08-04T23:36:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 4 Aug 2008, Shawn O. Pearce wrote:\n\n> James Linder wrote:\n>\n> > Jgit/Egit, on the other hand, appear to be tightly integrated with \n> > Jgit primarily supporting Egit.\n> \n> That's not really true.\n\nI started using jgit in a project that is not yet totally public. It is \nawesome. (I mean jgit is awesome, even if my project does make me happy, \ntoo.)\n\nAnd I absolutely share the puzzlement of Shawn why anybody would try to do \ntheir own thing in Java, instead of contributing to jgit.\n\nEspecially the fact that \"JavaGit\" seems to repeat the all-to-obvious \nerror of Eclipse: to make a platform-independent library that depends on \nplatform dependent components.\n\nI find that kind of thinking so strange, to the point that I am really \namazed enough to want to analyze the brain of the people inventing such \nthings.\n\nBut hey, maybe there is a deeper point in it that escapes me.\n\nCiao,\nDscho\n"},{"id":"86225","messageId":"489798EE.7050402@gmail.com","threadId":"14833","inReplyTo":"alpine.DEB.1.00.0808050127510.9611@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2008-08-05T00:03:58Z","receivedAt":"2008-08-05T00:03:58Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 4 Aug 2008, Shawn O. Pearce wrote:\n> \n>> James Linder wrote:\n>>\n>>> Jgit/Egit, on the other hand, appear to be tightly integrated with \n>>> Jgit primarily supporting Egit.\n>> That's not really true.\n> \n> I started using jgit in a project that is not yet totally public. It is \n> awesome. (I mean jgit is awesome, even if my project does make me happy, \n> too.)\n> \n> And I absolutely share the puzzlement of Shawn why anybody would try to do \n> their own thing in Java, instead of contributing to jgit.\n> \n> Especially the fact that \"JavaGit\" seems to repeat the all-to-obvious \n> error of Eclipse: to make a platform-independent library that depends on \n> platform dependent components.\n> \n> I find that kind of thinking so strange, to the point that I am really \n> amazed enough to want to analyze the brain of the people inventing such \n> things.\n> \n> But hey, maybe there is a deeper point in it that escapes me.\n\nYou mean like \"Why is a project with the goal of bringing the power of \ngit to Java developers hosted in svn instead of git\"?\n"},{"id":"86229","messageId":"20080805011051.GC32184@machine.or.cz","threadId":"14833","inReplyTo":"alpine.DEB.1.00.0808050127510.9611@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-05T01:10:51Z","receivedAt":"2008-08-05T01:10:51Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Aug 05, 2008 at 01:36:15AM +0200, Johannes Schindelin wrote:\n> And I absolutely share the puzzlement of Shawn why anybody would try to do \n> their own thing in Java, instead of contributing to jgit.\n> \n> Especially the fact that \"JavaGit\" seems to repeat the all-to-obvious \n> error of Eclipse: to make a platform-independent library that depends on \n> platform dependent components.\n\n[Totally naive question coming with no knowledge of actual size of\ncurrent JGit's feature set:]\n\nWouldn't it make sense to have an ability to fall back on Git calls for\nfunctionality that is not implemented natively yet? If you then don't\nhave Git available, you just don't get the functionality. What's the\ncatch?\n\n\nIt seems to me that JavaGit's goal is \"features, quick!\" where JGit's\ngoal is \"functionality, thoroughly\". Both goals seem legitimate to me,\nbut I'm also not sure why didn't JavaGit just extend JGit's missing bits\nwith native Git calls and instead opted for reimplementation from the\nground up.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"86230","messageId":"20080805012007.GB32543@spearce.org","threadId":"14833","inReplyTo":"20080805011051.GC32184@machine.or.cz","subject":"Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-05T01:20:07Z","receivedAt":"2008-08-05T01:20:07Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Petr Baudis wrote:\n> On Tue, Aug 05, 2008 at 01:36:15AM +0200, Johannes Schindelin wrote:\n> > And I absolutely share the puzzlement of Shawn why anybody would try to do \n> > their own thing in Java, instead of contributing to jgit.\n> > \n> > Especially the fact that \"JavaGit\" seems to repeat the all-to-obvious \n> > error of Eclipse: to make a platform-independent library that depends on \n> > platform dependent components.\n> \n> [Totally naive question coming with no knowledge of actual size of\n> current JGit's feature set:]\n> \n> Wouldn't it make sense to have an ability to fall back on Git calls for\n> functionality that is not implemented natively yet? If you then don't\n> have Git available, you just don't get the functionality. What's the\n> catch?\n\nSomeone else asked to do this in JGit before (it was privately\noff-list to Robin and myself). Both of our responses were that we\nwere not that interested in having such dependencies in the main\nJGit tree at this time, but that JGit is BSD and nothing would stop\nthem from forking our tree and trying it out. If there really was\nvalue there we would have to consider merging it back.\n\nNothing came of it as far as I know.\n\nSomeone recently ported git-blame into JGit, and it looks like they\ndid a good job, but it was a straight C->Java port. Since JGit\nis licensed under the BSD and builtin-blame.c is under the GPL we\ncouldn't accept it as-is. That side project produced a lot more\nresults than anything else of late, but the GPL virual clause kicked\nin and prevented direct inclusion.\n\n-- \nShawn.\n"},{"id":"86232","messageId":"59095A70-09C1-4898-976F-18C0C157B7EF@ai.rug.nl","threadId":"14833","inReplyTo":"20080805012007.GB32543@spearce.org","subject":"Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha","fromName":"Pieter de Bie","fromEmail":"pdebie@ai.rug.nl","sentAt":"2008-08-05T01:32:06Z","receivedAt":"2008-08-05T01:32:06Z","isPatch":false,"sender":{"key":"pdebie@ai.rug.nl","avatar":null},"body":"\nOn 5 aug 2008, at 03:20, Shawn O. Pearce wrote:\n\n> Someone recently ported git-blame into JGit, and it looks like they\n> did a good job, but it was a straight C->Java port. Since JGit\n> is licensed under the BSD and builtin-blame.c is under the GPL we\n> couldn't accept it as-is. That side project produced a lot more\n> results than anything else of late, but the GPL virual clause kicked\n> in and prevented direct inclusion.\n\nHave you asked the author of git-blame (Junio?) if he'd be willing to\nrelicence it to the JGit licences?\n\n- Pieter\n"},{"id":"86235","messageId":"20080805014647.GA383@spearce.org","threadId":"14833","inReplyTo":"59095A70-09C1-4898-976F-18C0C157B7EF@ai.rug.nl","subject":"Re: NYU Open Source Programming Class Releases JavaGit API 0.1.0 Alpha","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-05T01:46:47Z","receivedAt":"2008-08-05T01:46:47Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Pieter de Bie wrote:\n> On 5 aug 2008, at 03:20, Shawn O. Pearce wrote:\n>\n>> Someone recently ported git-blame into JGit, and it looks like they\n>> did a good job, but it was a straight C->Java port. Since JGit\n>> is licensed under the BSD and builtin-blame.c is under the GPL we\n>> couldn't accept it as-is. That side project produced a lot more\n>> results than anything else of late, but the GPL virual clause kicked\n>> in and prevented direct inclusion.\n>\n> Have you asked the author of git-blame (Junio?) if he'd be willing to\n> relicence it to the JGit licences?\n\nWe started talking about it off-list actually. I haven't heard\nback from Junio yet but I think he was hinting that he is open to\nthe idea.\n\n-- \nShawn.\n"}]}