{"thread":{"id":"558","subject":"Core and Not-So Core","startedAt":"2005-05-10T15:00:33Z","lastAt":"2005-05-18T18:35:16Z","messageCount":40,"participants":["Jon Seymour","David Woodhouse","Eduardo Teixeira Dias","Christoph Hellwig","Davide Libenzi","Diego Calleja","Daniel Barkalow","Petr Baudis","Andreas Gal","James Purser","Peter Williams","Rik van Riel","Nicolas Pitre","Noel Grandin","Juliusz Chroboczek"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"2976","messageId":"2cfc40320505100800426d38ca@mail.gmail.com","threadId":"558","inReplyTo":null,"subject":"Core and Not-So Core","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-10T15:00:33Z","receivedAt":"2005-05-10T15:00:33Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"I have been experimenting with pure-Java implementation of GIT\nconcepts with a goal of eventually providing plugins to Eclipse to\nallow the Eclipse GUI to interact with GIT repositories.\n\nOne thing I noticed when doing this is that the present index/cache\nstructure is rather arbitrary and the optimum index structure is\ndetermined by the structure of the tools that use a GIT repository\nrather than the structure of the GIT repository itself.\n\nTo give a concrete example: the cache currently contains most of the\nposix stat structure primarily to allow quick change detection. In the\nJava world, most of the posix stat structure is not directly\naccessible via the pure-Java file system abstractions. However, for\nmost purposes detecting changes to files modification time and file\nsize would be enough. Given this is the case, a Java-GIT client\ndoesn't need to bother getting access to a posix stat structure and\ncould therefore get away with a simpler index structure, provided it\ndoesn't need to interoperate with a 'C'-GIT client that shared the\nsame workspace. A Java-GIT client might also choose to represent an\nindex cache as a complex serialized Java object graph or (perhaps) an\nXML document.\n\nAnother example: I can imagine a variant of the index file structure\nthat recorded all the parents which have been merged into the cache\nand automatically include this information when performing the commit.\n\nThe point is that many different index file structures are possible\nand will be determined in part by the tooling created in the porcelain\nlayer - there really is no one true index file format as there is a\none true repository format. Different tools can use different index\nfile formats and still interoperate at the repository level because\nonly the repository format needs to have a solid, unchanging\ndefinition.\n\nCurrently the GIT stack is structured as follows:\n\ncogito\ngit-core \n\nI think it would be worthwhile if care was taken to draw a distinction\nbetween the repository and the cache aspects of the git core, perhaps\neven going to the extreme of moving all knowledge of the cache into\ncogito itself. By clearly drawing this distinction, we will more\neasily enable the creation of different kind of tools sets atop the\nfoundation of the GIT repository format.\n\ne.g., either:\n\ncogito\ngit-cache\ngit-respository\n\nor:\n\ncogito-tools\ncogito-cache\ngit-repository\n\nAnyway, I offer this as food for thought - chew or flame away as appropriate!\n\njon.\n-- \nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"},{"id":"2978","messageId":"1115739511.16187.432.camel@hades.cambridge.redhat.com","threadId":"558","inReplyTo":"2cfc40320505100800426d38ca@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-05-10T15:38:31Z","receivedAt":"2005-05-10T15:38:31Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Wed, 2005-05-11 at 01:00 +1000, Jon Seymour wrote:\n> I have been experimenting with pure-Java implementation of GIT\n> concepts with a goal of eventually providing plugins to Eclipse to\n> allow the Eclipse GUI to interact with GIT repositories.\n\nIt's not April 1st. Why would you want to reimplement it in Java instead\nof just using the existing implementation? Is this a religious issue?\n\n-- \ndwmw2\n\n"},{"id":"2979","messageId":"17115.200.158.14.67.1115740220.squirrel@www.tendencies.com.br","threadId":"558","inReplyTo":"1115739511.16187.432.camel@hades.cambridge.redhat.com","subject":"Re: Core and Not-So Core","fromName":"Eduardo Teixeira Dias","fromEmail":"eduardo@tendencies.com.br","sentAt":"2005-05-10T15:50:20Z","receivedAt":"2005-05-10T15:50:20Z","isPatch":false,"sender":{"key":"eduardo@tendencies.com.br","avatar":null},"body":"He want's to make an eclipce plugin...\n\nThis must be done in Java.\n\n> On Wed, 2005-05-11 at 01:00 +1000, Jon Seymour wrote:\n>> I have been experimenting with pure-Java implementation of GIT\n>> concepts with a goal of eventually providing plugins to Eclipse to\n>> allow the Eclipse GUI to interact with GIT repositories.\n>\n> It's not April 1st. Why would you want to reimplement it in Java instead\n> of just using the existing implementation? Is this a religious issue?\n>\n> --\n> dwmw2\n>\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n\n\n-- \n----------------------------\nEduardo Teixeira Dias\nTendencies Consultoria\nTel/Fax: +55 11 3828-1281\nhttp://www.tendencies.com.br\n\n\n"},{"id":"2980","messageId":"1115740844.16187.445.camel@hades.cambridge.redhat.com","threadId":"558","inReplyTo":"17115.200.158.14.67.1115740220.squirrel@www.tendencies.com.br","subject":"Re: Core and Not-So Core","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-05-10T16:00:44Z","receivedAt":"2005-05-10T16:00:44Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Tue, 2005-05-10 at 12:50 -0300, Eduardo Teixeira Dias wrote:\n> He want's to make an eclipce plugin...\n\nAnd there's no way for him to call execve()?\n\nHell, even the lisp nutters manage to make emacs invoke external\nprograms occasionally. What makes Java programmers so much less sane?\n\n-- \ndwmw2\n\n"},{"id":"2981","messageId":"26021.200.158.14.67.1115741989.squirrel@www.tendencies.com.br","threadId":"558","inReplyTo":"1115740844.16187.445.camel@hades.cambridge.redhat.com","subject":"Re: Core and Not-So Core","fromName":"Eduardo Teixeira Dias","fromEmail":"eduardo@tendencies.com.br","sentAt":"2005-05-10T16:19:49Z","receivedAt":"2005-05-10T16:19:49Z","isPatch":false,"sender":{"key":"eduardo@tendencies.com.br","avatar":null},"body":"\n> On Tue, 2005-05-10 at 12:50 -0300, Eduardo Teixeira Dias wrote:\n>> He want's to make an eclipce plugin...\n>\n> And there's no way for him to call execve()?\n>\n> Hell, even the lisp nutters manage to make emacs invoke external\n> programs occasionally. What makes Java programmers so much less sane?\n>\n> --\n> dwmw2\nGood point!\n\nIt can be done using execxxx().\n\nBut a Java version is better for this particular use (Eclipce Plugin):\n\n - Just a .jar download\n - Installation without external dependencies\n\n\n\n\n"},{"id":"2982","messageId":"2cfc4032050510092238259b63@mail.gmail.com","threadId":"558","inReplyTo":"1115739511.16187.432.camel@hades.cambridge.redhat.com","subject":"Re: Core and Not-So Core","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-10T16:22:45Z","receivedAt":"2005-05-10T16:22:45Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 5/11/05, David Woodhouse wrote:\n> On Wed, 2005-05-11 at 01:00 +1000, Jon Seymour wrote:\n> > I have been experimenting with pure-Java implementation of GIT\n> > concepts with a goal of eventually providing plugins to Eclipse to\n> > allow the Eclipse GUI to interact with GIT repositories.\n> \n> It's not April 1st. Why would you want to reimplement it in Java instead\n> of just using the existing implementation? Is this a religious issue?\n> \n\nNot really - in the Java world, things are simpler if you don't have\nto carry around a JNI library - that way, you can just run it wherever\na Java interpreter exists and not worry about\nhaving someone recompiling the JNI part. \n\nA pure-Java implementation will perform better than a\nJava-invokes-C-executable approach [ though not, of course, a C-only\napproach ].\n\nAnother benefit of playing around with a Java abstraction is that I\ncan more easily experiment with abstractions than I can in C since the\nabstraction-facilities of Java more directly support such playing than\ndoes C. So, for example, I can easily create a virtual repository\nwhich layers a local repository over a remote repository and\ntransparently populates the local repository from the remote\nrepository \"on-demand\". Of course, this sort of thing can be done in\nC, but it requires much more \"work\" to set up the abstractions.\n\nYou could perhaps argue that the existing 'C' tools in some way\nencapsulate access to the repository format. Maybe, but the fact is\nthe rapid adoption of GIT has already effectively fixed the GIT\nrepository format in practice so any change in repository format will\nrequire considerable planning anyway - planning that will allow\nsufficient time for implementations in other languages to catch up.\n\nSo, no, it's not a religious issue. If anything, it is being dogmatic\nto insist that the sacred GIT repository structure only be manipulated\nby 'C' tools blessed by the hands of Linus.\n\nThe concepts in GIT are bigger than the programming language its\ntoolsets are implemented in.\n\njon.\n-- \nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"},{"id":"2983","messageId":"1115744609.16187.455.camel@hades.cambridge.redhat.com","threadId":"558","inReplyTo":"2cfc4032050510092238259b63@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-05-10T17:03:29Z","receivedAt":"2005-05-10T17:03:29Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Wed, 2005-05-11 at 02:22 +1000, Jon Seymour wrote:\n> So, no, it's not a religious issue. If anything, it is being dogmatic\n> to insist that the sacred GIT repository structure only be manipulated\n> by 'C' tools blessed by the hands of Linus.\n\nGiven the volatility of the structure -- at least the details if not the\nfundamentals -- it seems bizarre to want to reimplement it rather than\njust using the existing tools.\n\nThis is the same mentality which gives Eclipse a half-arsed SSH\nreimplementation which doesn't behave like normal SSH is configured to\nbehave either, right?\n\n-- \ndwmw2\n\n"},{"id":"2984","messageId":"2cfc4032050510101553d391b2@mail.gmail.com","threadId":"558","inReplyTo":"2cfc403205051010151304d88a@mail.gmail.com","subject":"Core and Not-So Core","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-10T17:15:49Z","receivedAt":"2005-05-10T17:15:49Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 5/11/05, David Woodhouse wrote:\n> On Wed, 2005-05-11 at 02:22 +1000, Jon Seymour wrote:\n> > So, no, it's not a religious issue. If anything, it is being dogmatic\n> > to insist that the sacred GIT repository structure only be manipulated\n> > by 'C' tools blessed by the hands of Linus.\n>\n> Given the volatility of the structure -- at least the details if not the\n> fundamentals -- it seems bizarre to want to reimplement it rather than\n> just using the existing tools.\n\nI did consider wrapping it - I really did. But after thinking about it\nfor a couple of weeks\nI eventually came to the conclusion it would be a sub-optimal solution.\n\nAnd I don't agree that the structure is volatile. The actual structure\nof GIT repository has been rock-solid since Linus reversed the\ncompression-signature order. Yes, there has been the excellent delta\nwork that Nicholas has been working on, but a Java version doesn't\nneed to use that anymore than Linus himself does [ and last time I\nchecked (the mailing list), Linus was being rather conservative about\nthat ].\n\nWhat _has_ been changing at a great rate recently is the behaviour of\nthe tooling layer.\n\nSo, if I want a stable foundation to build my stuff on, basing it on\nthe output of the C tools would be a huge mistake. No, I think it\nwould be far safer for me to build my tooling using assumptions that\nhave proven to be rock-solid over the last few weeks - the structure\nof the GIT repository format itself.\n\n>\n> This is the same mentality which gives Eclipse a half-arsed SSH\n> reimplementation which doesn't behave like normal SSH is configured to\n> behave either, right?\n>\n\nDavid, I have nothing whatsoever to do with the Eclipse implementation\nof SSH, so what exactly is your point? All Java programmers are\nfundamentally brain-damaged? Grow up, please.\n\njon.\n-- \nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"},{"id":"2985","messageId":"1115745912.16187.468.camel@hades.cambridge.redhat.com","threadId":"558","inReplyTo":"2cfc4032050510101553d391b2@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-05-10T17:25:11Z","receivedAt":"2005-05-10T17:25:11Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Wed, 2005-05-11 at 03:15 +1000, Jon Seymour wrote:\n> David, I have nothing whatsoever to do with the Eclipse implementation\n> of SSH, so what exactly is your point? \n\nThat all programmers of _any_ persuasion who want to reimplement the\nworld in their own language instead of using existing tools are\nfundamentally brain-damaged. \n\nI'd say the same if the KDevelop people wanted to rewrite git and ssh in\nC++, too. \n\nI don't think that's such a childish observation, surely? Piecing\ntogether tools which do one thing, and do it well, is part of the UNIX\nphilosophy.\n\n-- \ndwmw2\n\n"},{"id":"2986","messageId":"2cfc4032050510103664ebef28@mail.gmail.com","threadId":"558","inReplyTo":"1115745912.16187.468.camel@hades.cambridge.redhat.com","subject":"Re: Core and Not-So Core","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-10T17:36:29Z","receivedAt":"2005-05-10T17:36:29Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 5/11/05, David Woodhouse wrote:\n> On Wed, 2005-05-11 at 03:15 +1000, Jon Seymour wrote:\n> > David, I have nothing whatsoever to do with the Eclipse implementation\n> > of SSH, so what exactly is your point?\n> \n> That all programmers of _any_ persuasion who want to reimplement the\n> world in their own language instead of using existing tools are\n> fundamentally brain-damaged.\n> \n> I'd say the same if the KDevelop people wanted to rewrite git and ssh in\n> C++, too.\n> \n> I don't think that's such a childish observation, surely? Piecing\n> together tools which do one thing, and do it well, is part of the UNIX\n> philosophy.\n\nThis might surprise you, but everything in the world is not a unix\ncommand line. Using tools designed for use on a unix command line in a\nhighly interactive environment like Eclipse would produce an\nabominably clunky result.\n\nPresumably you think this is the Unix way.\n\nI have already explained all the pragmatic reasons for doing a GIT\nimplementation in Java but you are prepared to ignore all of those\nreasons. You have ignored all these reasons rather than lift a finger\nto compose a well-reasoned rebuttal.\n\nInstead you cling to a dogmatic insistence that GIT respositories only\nbe accessed via the C toolsets.\n\nDavid, you are being extremely childish and extremely dogmatic. Why bother?\n\njon\n-- \nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"},{"id":"2987","messageId":"20050510174150.GA2072@infradead.org","threadId":"558","inReplyTo":"2cfc4032050510103664ebef28@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"Christoph Hellwig","fromEmail":"hch@infradead.org","sentAt":"2005-05-10T17:41:50Z","receivedAt":"2005-05-10T17:41:50Z","isPatch":false,"sender":{"key":"hch@infradead.org","avatar":null},"body":"On Wed, May 11, 2005 at 03:36:29AM +1000, Jon Seymour wrote:\n> This might surprise you, but everything in the world is not a unix\n> command line. Using tools designed for use on a unix command line in a\n> highly interactive environment like Eclipse would produce an\n> abominably clunky result.\n\n\nThe unix commandline is an highly interactive enviroment aswell,\nand supports scripting in addition :)\n\n> I have already explained all the pragmatic reasons for doing a GIT\n> implementation in Java but you are prepared to ignore all of those\n> reasons. You have ignored all these reasons rather than lift a finger\n> to compose a well-reasoned rebuttal.\n\nYou tried to argue for re-inventing the wheel. Fortunately you are\nallowed to reinvent the wheel here (which isn't given anymore these\ndays). Just don't expect any support from people who have been burnt\nby that before. And the Java world is re-inventing the wheel far to\noften - I suspect that'll be cured when the community gets more mature\nin a few years..\n\n> Instead you cling to a dogmatic insistence that GIT respositories only\n> be accessed via the C toolsets.\n\nThe C toolchain is a well-defined interface. One that makes a lot\nof sense.\n\n"},{"id":"2988","messageId":"2cfc403205051010514cf183e2@mail.gmail.com","threadId":"558","inReplyTo":"2cfc40320505101051207c9ce4@mail.gmail.com","subject":"Core and Not-So Core","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-10T17:51:40Z","receivedAt":"2005-05-10T17:51:40Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 5/11/05, Christoph Hellwig wrote:\n> On Wed, May 11, 2005 at 03:36:29AM +1000, Jon Seymour wrote:\n> > I have already explained all the pragmatic reasons for doing a GIT\n> > implementation in Java but you are prepared to ignore all of those\n> > reasons. You have ignored all these reasons rather than lift a finger\n> > to compose a well-reasoned rebuttal.\n>\n> You tried to argue for re-inventing the wheel. Fortunately you are\n> allowed to reinvent the wheel here (which isn't given anymore these\n> days). Just don't expect any support from people who have been burnt\n> by that before. And the Java world is re-inventing the wheel far to\n> often - I suspect that'll be cured when the community gets more mature\n> in a few years..\n>\n\nI am _not_ re-inventing any wheel. Merely building a road through\ndifferent territory upon which the GIT wheel may roll more freely.\n\nDon't get me wrong. I appreciate the UNIX mindset of building small\ntools and composing them freely. But the UNIX way isn't the only way\nto interact with the world and it is being hopelessly dogmatic to\ninsist otherwise.\n\njon.\n--\nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"},{"id":"2989","messageId":"Pine.LNX.4.63.0505101059380.10668@localhost.localdomain","threadId":"558","inReplyTo":"2cfc403205051010514cf183e2@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2005-05-10T18:01:56Z","receivedAt":"2005-05-10T18:01:56Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Wed, 11 May 2005, Jon Seymour wrote:\n\n> On 5/11/05, Christoph Hellwig wrote:\n>> On Wed, May 11, 2005 at 03:36:29AM +1000, Jon Seymour wrote:\n>>> I have already explained all the pragmatic reasons for doing a GIT\n>>> implementation in Java but you are prepared to ignore all of those\n>>> reasons. You have ignored all these reasons rather than lift a finger\n>>> to compose a well-reasoned rebuttal.\n>>\n>> You tried to argue for re-inventing the wheel. Fortunately you are\n>> allowed to reinvent the wheel here (which isn't given anymore these\n>> days). Just don't expect any support from people who have been burnt\n>> by that before. And the Java world is re-inventing the wheel far to\n>> often - I suspect that'll be cured when the community gets more mature\n>> in a few years..\n>>\n>\n> I am _not_ re-inventing any wheel. Merely building a road through\n> different territory upon which the GIT wheel may roll more freely.\n\nWould you mind fixing your mailer before, so that your messages won't \nappear as new Subject: every time?\n\n\n- Davide\n\n"},{"id":"2994","messageId":"20050510234501.79eea7a4.diegocg@gmail.com","threadId":"558","inReplyTo":"26021.200.158.14.67.1115741989.squirrel@www.tendencies.com.br","subject":"Re: Core and Not-So Core","fromName":"Diego Calleja","fromEmail":"diegocg@gmail.com","sentAt":"2005-05-10T21:45:01Z","receivedAt":"2005-05-10T21:45:01Z","isPatch":false,"sender":{"key":"diegocg@gmail.com","avatar":null},"body":"El Tue, 10 May 2005 13:19:49 -0300 (BRT),\n\"Eduardo Teixeira Dias\" escribió:\n\n> - Just a .jar download\n> - Installation without external dependencies\n\n\nSomeone who is going to hack the kernel can very well install more things.\nAnd anyway, git is \"the linux SCM tool\" so all distros will package it. Also,\npeople who hacks the linux kernel usually runs it, so \"git is not ported\nto win32\" is not a big problem.\n\n...and I don't think people who use eclipse wants to have the fastest tool\non earth, so \"java-invoking-C is slower than pure java\" is not a great excuse\neither...\n\nCode reuse == good. Java programmers should know that. Anyway, people\nis free to do whatever they want with their time :)\n"},{"id":"2999","messageId":"Pine.LNX.4.21.0505101743520.30848-100000@iabervon.org","threadId":"558","inReplyTo":"2cfc40320505100800426d38ca@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-05-10T22:18:09Z","receivedAt":"2005-05-10T22:18:09Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 11 May 2005, Jon Seymour wrote:\n\n> I have been experimenting with pure-Java implementation of GIT\n> concepts with a goal of eventually providing plugins to Eclipse to\n> allow the Eclipse GUI to interact with GIT repositories.\n> \n> One thing I noticed when doing this is that the present index/cache\n> structure is rather arbitrary and the optimum index structure is\n> determined by the structure of the tools that use a GIT repository\n> rather than the structure of the GIT repository itself.\n\nI'd guess that an Eclipse plugin wouldn't have a on-disk cache at all,\nsince it expects to keep the same address space through a whole day's\nwork.\n\n> To give a concrete example: the cache currently contains most of the\n> posix stat structure primarily to allow quick change detection. In the\n> Java world, most of the posix stat structure is not directly\n> accessible via the pure-Java file system abstractions. However, for\n> most purposes detecting changes to files modification time and file\n> size would be enough. Given this is the case, a Java-GIT client\n> doesn't need to bother getting access to a posix stat structure and\n> could therefore get away with a simpler index structure, provided it\n> doesn't need to interoperate with a 'C'-GIT client that shared the\n> same workspace. A Java-GIT client might also choose to represent an\n> index cache as a complex serialized Java object graph or (perhaps) an\n> XML document.\n\nThe two clients should be able to interoperate trivially; the C version\nwould just treat the Java one as a text editor whose modifications happen\nto match commits going into the same head; as soon as the C user does\neither read-tree or update-cache, everything will be seen to be consistent\nagain.\n\n> Currently the GIT stack is structured as follows:\n> \n> cogito\n> git-core \n> \n> I think it would be worthwhile if care was taken to draw a distinction\n> between the repository and the cache aspects of the git core, perhaps\n> even going to the extreme of moving all knowledge of the cache into\n> cogito itself. By clearly drawing this distinction, we will more\n> easily enable the creation of different kind of tools sets atop the\n> foundation of the GIT repository format.\n\nI think this is nonsensical. The cache format is tied to the way in which\nthe repository accessing code is written, so a git-core separate from the\ncache wouldn't have a useful set of code.\n\nIt might be worthwhile to produce a separate document describing the\nrepository format, such that it could be accessed by different code,\nhowever. Of course, the index file wouldn't be part of this documentation,\nfor the same reason that the public git repositories don't include index\nfiles.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"3000","messageId":"58433.200.158.14.67.1115764394.squirrel@www.tendencies.com.br","threadId":"558","inReplyTo":"20050510234501.79eea7a4.diegocg@gmail.com","subject":"Re: Core and Not-So Core","fromName":"Eduardo Teixeira Dias","fromEmail":"eduardo@tendencies.com.br","sentAt":"2005-05-10T22:33:14Z","receivedAt":"2005-05-10T22:33:14Z","isPatch":false,"sender":{"key":"eduardo@tendencies.com.br","avatar":null},"body":"I'm a Java programmer and I was thinking like one (Culture thing).\n\nThe reuse argument is very Strong.\n\nThe git-core are ready and it's a very good idea to reuse it. Any change\nin the core or in the internal representation of git repository will\nbenefit the Git-Java implementation...\n\nI think that a growing utilization of GCJ and ClassPath will contribute to\na Gradual Culture Change in the Java Land and promote a beter\nreutilization among all GCC languages...\n\nWrite Once Run Everywhere that GCJ Runs (Sounds Good).\n\nEclipse will be compiled with GCJ in Fedora 4. Let's see how it works...\n\nCheers!\n\n> El Tue, 10 May 2005 13:19:49 -0300 (BRT),\n> \"Eduardo Teixeira Dias\" escribió:\n>\n>> - Just a .jar download\n>> - Installation without external dependencies\n>\n>\n> Someone who is going to hack the kernel can very well install more\n> things. And anyway, git is \"the linux SCM tool\" so all distros will\n> package it. Also, people who hacks the linux kernel usually runs it, so\n> \"git is not ported to win32\" is not a big problem.\n>\n> ...and I don't think people who use eclipse wants to have the fastest\n> tool on earth, so \"java-invoking-C is slower than pure java\" is not a\n> great excuse either...\n>\n> Code reuse == good. Java programmers should know that. Anyway, people is\n> free to do whatever they want with their time :)\n\n\n\n\n"},{"id":"3001","messageId":"62633.200.158.14.67.1115764428.squirrel@www.tendencies.com.br","threadId":"558","inReplyTo":"20050510234501.79eea7a4.diegocg@gmail.com","subject":"Re: Core and Not-So Core","fromName":"Eduardo Teixeira Dias","fromEmail":"eduardo@tendencies.com.br","sentAt":"2005-05-10T22:33:48Z","receivedAt":"2005-05-10T22:33:48Z","isPatch":false,"sender":{"key":"eduardo@tendencies.com.br","avatar":null},"body":"I'm a Java programmer and I was thinking like one (Culture thing).\n\nThe reuse argument is very Strong.\n\nThe git-core are ready and it's a very good idea to reuse it. Any change\nin the core or in the internal representation of git repository will\nbenefit the Git-Java implementation...\n\nI think that a growing utilization of GCJ and ClassPath will contribute to\na Gradual Culture Change in the Java Land and promote a beter\nreutilization among all GCC languages...\n\nWrite Once Run Everywhere that GCJ Runs (Sounds Good).\n\nEclipse will be compiled with GCJ in Fedora 4. Let's see how it works...\n\nCheers!\n\n> El Tue, 10 May 2005 13:19:49 -0300 (BRT),\n> \"Eduardo Teixeira Dias\" escribió:\n>\n>> - Just a .jar download\n>> - Installation without external dependencies\n>\n>\n> Someone who is going to hack the kernel can very well install more\n> things. And anyway, git is \"the linux SCM tool\" so all distros will\n> package it. Also, people who hacks the linux kernel usually runs it, so\n> \"git is not ported to win32\" is not a big problem.\n>\n> ...and I don't think people who use eclipse wants to have the fastest\n> tool on earth, so \"java-invoking-C is slower than pure java\" is not a\n> great excuse either...\n>\n> Code reuse == good. Java programmers should know that. Anyway, people is\n> free to do whatever they want with their time :)\n\n\n\n\n"},{"id":"3002","messageId":"1520.200.158.14.67.1115764452.squirrel@www.tendencies.com.br","threadId":"558","inReplyTo":"20050510234501.79eea7a4.diegocg@gmail.com","subject":"Re: Core and Not-So Core","fromName":"Eduardo Teixeira Dias","fromEmail":"eduardo@tendencies.com.br","sentAt":"2005-05-10T22:34:12Z","receivedAt":"2005-05-10T22:34:12Z","isPatch":false,"sender":{"key":"eduardo@tendencies.com.br","avatar":null},"body":"I'm a Java programmer and I was thinking like one (Culture thing).\n\nThe reuse argument is very Strong.\n\nThe git-core are ready and it's a very good idea to reuse it. Any change\nin the core or in the internal representation of git repository will\nbenefit the Git-Java implementation...\n\nI think that a growing utilization of GCJ and ClassPath will contribute to\na Gradual Culture Change in the Java Land and promote a beter\nreutilization among all GCC languages...\n\nWrite Once Run Everywhere that GCJ Runs (Sounds Good).\n\nEclipse will be compiled with GCJ in Fedora 4. Let's see how it works...\n\nCheers!\n\n> El Tue, 10 May 2005 13:19:49 -0300 (BRT),\n> \"Eduardo Teixeira Dias\" escribió:\n>\n>> - Just a .jar download\n>> - Installation without external dependencies\n>\n>\n> Someone who is going to hack the kernel can very well install more\n> things. And anyway, git is \"the linux SCM tool\" so all distros will\n> package it. Also, people who hacks the linux kernel usually runs it, so\n> \"git is not ported to win32\" is not a big problem.\n>\n> ...and I don't think people who use eclipse wants to have the fastest\n> tool on earth, so \"java-invoking-C is slower than pure java\" is not a\n> great excuse either...\n>\n> Code reuse == good. Java programmers should know that. Anyway, people is\n> free to do whatever they want with their time :)\n\n\n\n\n"},{"id":"3003","messageId":"20050510224433.GC26384@pasky.ji.cz","threadId":"558","inReplyTo":"20050510234501.79eea7a4.diegocg@gmail.com","subject":"Re: Core and Not-So Core","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-10T22:44:33Z","receivedAt":"2005-05-10T22:44:33Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, May 10, 2005 at 11:45:01PM CEST, I got a letter\nwhere Diego Calleja told me that...\n> Someone who is going to hack the kernel can very well install more things.\n> And anyway, git is \"the linux SCM tool\" so all distros will package it. Also,\n> people who hacks the linux kernel usually runs it, so \"git is not ported\n> to win32\" is not a big problem.\n\nIt's not like everything git is ever going to be used for is kernel and\nonly the kernel.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"3004","messageId":"20050510225235.GD26384@pasky.ji.cz","threadId":"558","inReplyTo":"2cfc40320505100800426d38ca@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-10T22:52:35Z","receivedAt":"2005-05-10T22:52:35Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, May 10, 2005 at 05:00:33PM CEST, I got a letter\nwhere Jon Seymour told me that...\n> One thing I noticed when doing this is that the present index/cache\n> structure is rather arbitrary and the optimum index structure is\n> determined by the structure of the tools that use a GIT repository\n> rather than the structure of the GIT repository itself.\n\nYes. And that's how it should be - the directory cache is just that - a\n_cache_. It does not hold any permanent information, merely serves to\nrecord git tools' working state relative to the given working tree. So\nunlike the objects database which has well-defined format and is\nsupposed to be \"public\", you should view the directory cache as internal\ngit tools' structure. If you want to mess with it too, either use the\nproper level of abstraction and call the git tools, or don't mess with\nit at all. And you need to care about it only if you want the git tools\nworking on the same tree properly too - so in that case use the git\ntools too.\n\n From your arguments, it's not clear to me what really is the big\nproblem with the git tools. They are _designed_ for automatic use\ninstead of human interaction - you can perceive them just as methods\nwith funny (but actually friendly to your programs) calling convention.\n\nKind regards,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"3005","messageId":"Pine.LNX.4.58.0505101552500.29765@sam.ics.uci.edu","threadId":"558","inReplyTo":"20050510224433.GC26384@pasky.ji.cz","subject":"Re: Core and Not-So Core","fromName":"Andreas Gal","fromEmail":"gal@uci.edu","sentAt":"2005-05-10T22:54:58Z","receivedAt":"2005-05-10T22:54:58Z","isPatch":false,"sender":{"key":"gal@uci.edu","avatar":null},"body":"\nBtw, I rewrote about 90% of git in python, just out of curiousity. \nPerformance is pretty competitive, and I can optimize certain operations \nby keeping the index in memory temporarily. It also saves a lot of output \nparsing, simplifies error-handling (if the frontend is written in python \ntoo, which bit now is), and the best of all: its about 600 lines of python \ncode. I am all for a Java implementation. After its done we will see \nwhether it works and how well it works. We can still throw it away if it \nsucks. \n\nAndreas\n\nOn Wed, 11 May 2005, Petr Baudis wrote:\n\n> Dear diary, on Tue, May 10, 2005 at 11:45:01PM CEST, I got a letter\n> where Diego Calleja told me that...\n> > Someone who is going to hack the kernel can very well install more things.\n> > And anyway, git is \"the linux SCM tool\" so all distros will package it. Also,\n> > people who hacks the linux kernel usually runs it, so \"git is not ported\n> > to win32\" is not a big problem.\n> \n> It's not like everything git is ever going to be used for is kernel and\n> only the kernel.\n> \n> -- \n> \t\t\t\tPetr \"Pasky\" Baudis\n> Stuff: http://pasky.or.cz/\n> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"3007","messageId":"20050511010302.3ab47c74.diegocg@gmail.com","threadId":"558","inReplyTo":"58433.200.158.14.67.1115764394.squirrel@www.tendencies.com.br","subject":"Re: Core and Not-So Core","fromName":"Diego Calleja","fromEmail":"diegocg@gmail.com","sentAt":"2005-05-10T23:03:02Z","receivedAt":"2005-05-10T23:03:02Z","isPatch":false,"sender":{"key":"diegocg@gmail.com","avatar":null},"body":"[somewhat OT]\n\nEl Tue, 10 May 2005 19:33:14 -0300 (BRT),\n\"Eduardo Teixeira Dias\" escribió:\n\n> Write Once Run Everywhere that GCJ Runs (Sounds Good).\n\nGCJ in fact supports more architectures than Sun's java VM so with GCJ you _really_\ncan run your java code everywhere.\n\n"},{"id":"3008","messageId":"1115766261.3068.0.camel@kryten","threadId":"558","inReplyTo":"20050510224433.GC26384@pasky.ji.cz","subject":"Re: Core and Not-So Core","fromName":"James Purser","fromEmail":"purserj@ksit.dynalias.com","sentAt":"2005-05-10T23:04:21Z","receivedAt":"2005-05-10T23:04:21Z","isPatch":false,"sender":{"key":"purserj@ksit.dynalias.com","avatar":null},"body":"On Wed, 2005-05-11 at 08:44, Petr Baudis wrote:\n> Dear diary, on Tue, May 10, 2005 at 11:45:01PM CEST, I got a letter\n> where Diego Calleja told me that...\n> > Someone who is going to hack the kernel can very well install more things.\n> > And anyway, git is \"the linux SCM tool\" so all distros will package it. Also,\n> > people who hacks the linux kernel usually runs it, so \"git is not ported\n> > to win32\" is not a big problem.\n> \n> It's not like everything git is ever going to be used for is kernel and\n> only the kernel.\nSo does this mean I can keep working on my wxWidgets implementation? :)\n-- \nJames Purser\nhttp://ksit.dynalias.com\n\n"},{"id":"3010","messageId":"2cfc4032050510160578b81fa7@mail.gmail.com","threadId":"558","inReplyTo":"2cfc40320505101605721420@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-10T23:05:55Z","receivedAt":"2005-05-10T23:05:55Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":">\n> > I think it would be worthwhile if care was taken to draw a distinction\n> > between the repository and the cache aspects of the git core, perhaps\n> > even going to the extreme of moving all knowledge of the cache into\n> > cogito itself. By clearly drawing this distinction, we will more\n> > easily enable the creation of different kind of tools sets atop the\n> > foundation of the GIT repository format.\n>\n> I think this is nonsensical. The cache format is tied to the way in which\n> the repository accessing code is written, so a git-core separate from the\n> cache wouldn't have a useful set of code.\n>\n\nI guess I agree it is somewhat nonsensical if one considers the\ncurrent git toolset as a collection of programs - the exercise now\nmight simply reduce to classifying git tools as\nindex-using/non-index-using and nothing more. However, it might be\nworth keeping in mind when/if the \"libification\" of git happens so\nthat there is a clean separation of layers in the API between the\nrepository API and index/cache/workspace API.\n\n> It might be worthwhile to produce a separate document describing the\n> repository format, such that it could be accessed by different code,\n> however. Of course, the index file wouldn't be part of this documentation,\n> for the same reason that the public git repositories don't include index\n> files.\n>\n\nAnd thanks for your constructive criticism.\n\njon.\n--\nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"},{"id":"3011","messageId":"20050510230844.GG26384@pasky.ji.cz","threadId":"558","inReplyTo":"2cfc4032050510160578b81fa7@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-10T23:08:44Z","receivedAt":"2005-05-10T23:08:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, May 11, 2005 at 01:05:55AM CEST, I got a letter\nwhere Jon Seymour told me that...\n> >\n> > > I think it would be worthwhile if care was taken to draw a distinction\n> > > between the repository and the cache aspects of the git core, perhaps\n> > > even going to the extreme of moving all knowledge of the cache into\n> > > cogito itself. By clearly drawing this distinction, we will more\n> > > easily enable the creation of different kind of tools sets atop the\n> > > foundation of the GIT repository format.\n> >\n> > I think this is nonsensical. The cache format is tied to the way in which\n> > the repository accessing code is written, so a git-core separate from the\n> > cache wouldn't have a useful set of code.\n> >\n> \n> I guess I agree it is somewhat nonsensical if one considers the\n> current git toolset as a collection of programs - the exercise now\n> might simply reduce to classifying git tools as\n> index-using/non-index-using and nothing more. However, it might be\n> worth keeping in mind when/if the \"libification\" of git happens so\n> that there is a clean separation of layers in the API between the\n> repository API and index/cache/workspace API.\n\nIn that case the repository API's input/output is data structure\nequivalent to the index, and workspace API's input/output is the index\ntoo. That is what it really is - and it is kept on the disk only since\nthe commands are invoked separately so it needs to keep the state around\nsomewhere.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"3013","messageId":"2cfc403205051016205d722f23@mail.gmail.com","threadId":"558","inReplyTo":"20050510230844.GG26384@pasky.ji.cz","subject":"Re: Core and Not-So Core","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-10T23:20:42Z","receivedAt":"2005-05-10T23:20:42Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 5/11/05, Petr Baudis wrote:\n> Dear diary, on Wed, May 11, 2005 at 01:05:55AM CEST, I got a letter\n> where Jon Seymour told me that...\n> >\n> > I guess I agree it is somewhat nonsensical if one considers the\n> > current git toolset as a collection of programs - the exercise now\n> > might simply reduce to classifying git tools as\n> > index-using/non-index-using and nothing more. However, it might be\n> > worth keeping in mind when/if the \"libification\" of git happens so\n> > that there is a clean separation of layers in the API between the\n> > repository API and index/cache/workspace API.\n> \n> In that case the repository API's input/output is data structure\n> equivalent to the index, and workspace API's input/output is the index\n> too. That is what it really is - and it is kept on the disk only since\n> the commands are invoked separately so it needs to keep the state around\n> somewhere.\n> \n\nNot sure I agree...\n\nThe repository API would contain functionality equivalent to cat-file,\nls-tree, most of fsck-cache, rev-list, rev-tree, diff-tree, most of\nthe transport code - things that don't involve use of the index.\n\nThe workspace API would contain read-tree, write-tree, commit-tree,\netc - things that do involve use of the the index.\n\njon.\n"},{"id":"3015","messageId":"2cfc403205051017505b57da72@mail.gmail.com","threadId":"558","inReplyTo":"20050510225235.GD26384@pasky.ji.cz","subject":"Re: Core and Not-So Core","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-11T00:50:00Z","receivedAt":"2005-05-11T00:50:00Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 5/11/05, Petr Baudis wrote:\n> Dear diary, on Tue, May 10, 2005 at 05:00:33PM CEST, I got a letter\n> where Jon Seymour told me that...\n> \n> Yes. And that's how it should be - the directory cache is just that - a\n> _cache_. \n\nNo argument there.\n\n> So unlike the objects database which has well-defined format and is\n> supposed to be \"public\", you should view the directory cache as internal\n> git tools' structure. If you want to mess with it too, either use the\n> proper level of abstraction and call the git tools, or don't mess with\n> it at all. And you need to care about it only if you want the git tools\n> working on the same tree properly too - so in that case use the git\n> tools too.\n\nI agree in principle, though I'd like users to be able to easily\nswitch between the Eclipse and git tools view of the workspace if they\nwant to - who am I to say how a user should work? Eclipse does this\nkind of thing quite well with CVS precisely because it shares the\nworkspace structures with the CVS command line tools rather than\n\"re-inventing\" the wheel. Yes, separation of concerns has been lost\n(two implementations of a CVS client), but the big win is that the\ntools behave like the user wants them to behave.\n\nThe trickiest case here is when the user switches between toolsets\nmid-merge. I guess what I can do is this:\n\nuser switch from eclipse -> to git-tools:\n 1. blow away existing git tools index\n 2. use git-read-tree to repeat the merge executed in eclipse (my\nworkspace will track parents)\n 3. use git-update-cache --add/--remove to reflect merge actions\nthat have occurred since the workspace deviated from the HEAD.\n\nAlternatively, I can just make Eclipse reflect cache changing actions\nout onto the git-tools, via an exec of those tools, as and when they\noccur.\n\nMaking use of the git tools index going the other way isn't so easy to\nachieve because the git tools workspace as it stands doesn't track the\nmerges that have occurred (i.e. which parents were used to form the\ncurrent cache). However, that's not necessarily a big problem. I just\nrebuild my \"cache\" from scratch based on the merges I know about and\ntreat every other difference from the HEAD as a user edit to the\nworkspace.\n \n> \n> From your arguments, it's not clear to me what really is the big\n> problem with the git tools. They are _designed_ for automatic use\n> instead of human interaction - you can perceive them just as methods\n> with funny (but actually friendly to your programs) calling convention.\n> \n\nI am not really arguing that there is a big problem with the existing\ngit tools. However, what I am arguing is that the existing workspace\ntools are just one way to manage the workspace (Eclipse might be\nanother, as an example) and it would be helpful to keep this in mind,\nparticularly when/if libification ever happens.\n\njon.\n"},{"id":"3017","messageId":"42815D33.60905@bigpond.net.au","threadId":"558","inReplyTo":"2cfc403205051017505b57da72@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"Peter Williams","fromEmail":"pwil3058@bigpond.net.au","sentAt":"2005-05-11T01:17:39Z","receivedAt":"2005-05-11T01:17:39Z","isPatch":false,"sender":{"key":"pwil3058@bigpond.net.au","avatar":"https://gravatar.com/avatar/fc711ad9d9890c01c6ede5a99a62a8b8ca82a3eef0def8ef98e0ec7da7f99367?d=mp&s=160"},"body":"Jon Seymour wrote:\n> On 5/11/05, Petr Baudis wrote:\n> \n>>Dear diary, on Tue, May 10, 2005 at 05:00:33PM CEST, I got a letter\n>>where Jon Seymour told me that...\n>>\n>>Yes. And that's how it should be - the directory cache is just that - a\n>>_cache_. \n> \n> \n> No argument there.\n> \n> \n>> So unlike the objects database which has well-defined format and is\n>>supposed to be \"public\", you should view the directory cache as internal\n>>git tools' structure. If you want to mess with it too, either use the\n>>proper level of abstraction and call the git tools, or don't mess with\n>>it at all. And you need to care about it only if you want the git tools\n>>working on the same tree properly too - so in that case use the git\n>>tools too.\n> \n> \n> I agree in principle, though I'd like users to be able to easily\n> switch between the Eclipse and git tools view of the workspace if they\n> want to - who am I to say how a user should work? Eclipse does this\n> kind of thing quite well with CVS precisely because it shares the\n> workspace structures with the CVS command line tools rather than\n> \"re-inventing\" the wheel.\n\nI disagree here. My experience is that Eclipse does not work well with \ncommand line use of CVS within one of its workspaces. This is because \nEclipse keeps too much \"state\" information internally instead of relying \non CVS for all information about the state of the CVS playground. This \nis one of the reasons that you can't attach Eclipse to an already \nchecked out CVS playground. The problem should be easily avoidable.\n\nIn spite of the above, Eclipse's SCM interface is the best that I've \nstumbled across and is the main reason that I use Eclipse. I \nparticularly like the ability to compare a file in the workspace with \nthose in different versions, branches, etc.\n\nSo I'm looking forward to a git plug-in.\n\nPeter\n-- \nPeter Williams pwil3058@bigpond.net.au\n\n\"Learning, n. The kind of ignorance distinguishing the studious.\"\n -- Ambrose Bierce\n"},{"id":"3021","messageId":"Pine.LNX.4.61.0505102158140.17216@chimarrao.boston.redhat.com","threadId":"558","inReplyTo":"2cfc4032050510101553d391b2@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"Rik van Riel","fromEmail":"riel@redhat.com","sentAt":"2005-05-11T01:59:22Z","receivedAt":"2005-05-11T01:59:22Z","isPatch":false,"sender":{"key":"riel@redhat.com","avatar":null},"body":"On Wed, 11 May 2005, Jon Seymour wrote:\n\n> I did consider wrapping it - I really did. But after thinking about it \n> for a couple of weeks I eventually came to the conclusion it would be a \n> sub-optimal solution.\n\n> So, if I want a stable foundation to build my stuff on, basing it on\n> the output of the C tools would be a huge mistake.\n\nCan Java use a library that's implemented in C, like Python\nand Perl can? If that is the case, the C implementation of\ngit simply needs the ability to be called as a library and\nyou can implement Java bindings for it.\n\nThat should also make it easier to create front-ends in\nother languages...\n\n-- \n\"Debugging is twice as hard as writing the code in the first place.\nTherefore, if you write the code as cleverly as possible, you are,\nby definition, not smart enough to debug it.\" - Brian W. Kernighan\n"},{"id":"3023","messageId":"2cfc4032050510190950bba995@mail.gmail.com","threadId":"558","inReplyTo":"Pine.LNX.4.61.0505102158140.17216@chimarrao.boston.redhat.com","subject":"Re: Core and Not-So Core","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-11T02:09:49Z","receivedAt":"2005-05-11T02:09:49Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 5/11/05, Rik van Riel wrote:\n> On Wed, 11 May 2005, Jon Seymour wrote:\n> \n> > I did consider wrapping it - I really did. But after thinking about it\n> > for a couple of weeks I eventually came to the conclusion it would be a\n> > sub-optimal solution.\n> \n> > So, if I want a stable foundation to build my stuff on, basing it on\n> > the output of the C tools would be a huge mistake.\n> \n> Can Java use a library that's implemented in C, like Python\n> and Perl can? If that is the case, the C implementation of\n> git simply needs the ability to be called as a library and\n> you can implement Java bindings for it.\n> \n\nIt can in principle, yes. This is the so-called Java-Native-Interface (JNI).\n\nI think in the longer term it would make sense to write a JNI layer\nbut the GIT source code is probably a little too unstable for that\nnow. What needs to happen first, I think, is that a solid and stable C\nAPI (e.g. a libgit) be proposed and developed.\n\nOne outcome of the work I am doing (a long time away, probably will\nnever happen) might eventually be to propose an C API for GIT based,\nin part, on the prototyping work I do in Java. However, I suspect its\nJava-tainted heritage would mean instant death to it for purely\ndogmatic reasons so I think it I'll leave it to others to propose a\nC-API and then write a JNI wrapper for that when/if it ever happens.\n\n> That should also make it easier to create front-ends in\n> other languages...\n> \n\nAgreed.\n\njon.\n"},{"id":"3024","messageId":"20050511021413.GN26384@pasky.ji.cz","threadId":"558","inReplyTo":"2cfc4032050510190950bba995@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-11T02:14:13Z","receivedAt":"2005-05-11T02:14:13Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, May 11, 2005 at 04:09:49AM CEST, I got a letter\nwhere Jon Seymour told me that...\n> On 5/11/05, Rik van Riel wrote:\n> > On Wed, 11 May 2005, Jon Seymour wrote:\n> > \n> > > I did consider wrapping it - I really did. But after thinking about it\n> > > for a couple of weeks I eventually came to the conclusion it would be a\n> > > sub-optimal solution.\n> > \n> > > So, if I want a stable foundation to build my stuff on, basing it on\n> > > the output of the C tools would be a huge mistake.\n> > \n> > Can Java use a library that's implemented in C, like Python\n> > and Perl can? If that is the case, the C implementation of\n> > git simply needs the ability to be called as a library and\n> > you can implement Java bindings for it.\n> > \n> \n> It can in principle, yes. This is the so-called Java-Native-Interface (JNI).\n> \n> I think in the longer term it would make sense to write a JNI layer\n> but the GIT source code is probably a little too unstable for that\n> now. What needs to happen first, I think, is that a solid and stable C\n> API (e.g. a libgit) be proposed and developed.\n\nFWIW, this is actually happening now (see Brad Roberts' posts in nearby\nthread).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"3025","messageId":"Pine.LNX.4.62.0505102226020.5426@localhost.localdomain","threadId":"558","inReplyTo":"2cfc403205051017505b57da72@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2005-05-11T02:30:21Z","receivedAt":"2005-05-11T02:30:21Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 11 May 2005, Jon Seymour wrote:\n\n> On 5/11/05, Petr Baudis wrote:\n> > So unlike the objects database which has well-defined format and is\n> > supposed to be \"public\", you should view the directory cache as internal\n> > git tools' structure. If you want to mess with it too, either use the\n> > proper level of abstraction and call the git tools, or don't mess with\n> > it at all. And you need to care about it only if you want the git tools\n> > working on the same tree properly too - so in that case use the git\n> > tools too.\n> \n> I agree in principle, though I'd like users to be able to easily\n> switch between the Eclipse and git tools view of the workspace if they\n> want to - who am I to say how a user should work? Eclipse does this\n> kind of thing quite well with CVS precisely because it shares the\n> workspace structures with the CVS command line tools rather than\n> \"re-inventing\" the wheel.\n\nIn this case you just need to manage to use the current index format \nsomehow. \n\nHonestly I don't think Linus might be interested into changing the index \nformat just to make a Java implementation happier. So your best bet is \nprobably to use it as is or ignore it entirely.\n\n\nNicolas\n"},{"id":"3027","messageId":"2cfc403205051020023e84ec7b@mail.gmail.com","threadId":"558","inReplyTo":"Pine.LNX.4.62.0505102226020.5426@localhost.localdomain","subject":"Re: Core and Not-So Core","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-11T03:02:19Z","receivedAt":"2005-05-11T03:02:19Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 5/11/05, Nicolas Pitre wrote:\n> On Wed, 11 May 2005, Jon Seymour wrote:\n> > I agree in principle, though I'd like users to be able to easily\n> > switch between the Eclipse and git tools view of the workspace if they\n> > want to - who am I to say how a user should work? Eclipse does this\n> > kind of thing quite well with CVS precisely because it shares the\n> > workspace structures with the CVS command line tools rather than\n> > \"re-inventing\" the wheel.\n> \n> In this case you just need to manage to use the current index format\n> somehow.\n> \n> Honestly I don't think Linus might be interested into changing the index\n> format just to make a Java implementation happier. So your best bet is\n> probably to use it as is or ignore it entirely.\n> \n\nAgreed - I am not proposing a change to the index format, merely\nhighlighting that the index format is closely bound to the\nworkspace-oriented toolset and that the workspace-oriented toolset is\ndistinct from the repository-oriented toolset; different\nworkspace-oriented toolsets will have different requirements for their\nindex files and so their index files might quite rightly differ in\nboth form and substance.\n\nThat said, their is no harm making my set of tools interoperable with\nthe git tools, where that is possible so that the user can decide to\nuse which ever toolset fits the job immediately at hand. With this in\nmind, a published specification of the index format would help, but I\nam not going insist on that. I am certainly not going to ask for\nchanges to it! Life is too short :-)\n\njon.\n"},{"id":"3033","messageId":"20050511071717.GB23090@infradead.org","threadId":"558","inReplyTo":"20050510234501.79eea7a4.diegocg@gmail.com","subject":"Re: Core and Not-So Core","fromName":"Christoph Hellwig","fromEmail":"hch@infradead.org","sentAt":"2005-05-11T07:17:17Z","receivedAt":"2005-05-11T07:17:17Z","isPatch":false,"sender":{"key":"hch@infradead.org","avatar":null},"body":"On Tue, May 10, 2005 at 11:45:01PM +0200, Diego Calleja wrote:\n> ...and I don't think people who use eclipse wants to have the fastest tool\n> on earth, so \"java-invoking-C is slower than pure java\" is not a great excuse\n> either...\n\nNote that it's also not true. At least if you use the gcj-specific CNI\nmechanisms instead of Sun's braindead JNI.\n\n"},{"id":"3035","messageId":"2cfc403205051100421a2ffa7e@mail.gmail.com","threadId":"558","inReplyTo":"20050511071717.GB23090@infradead.org","subject":"Re: Core and Not-So Core","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-11T07:42:27Z","receivedAt":"2005-05-11T07:42:27Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 5/11/05, Christoph Hellwig wrote:\n> On Tue, May 10, 2005 at 11:45:01PM +0200, Diego Calleja wrote:\n> > ...and I don't think people who use eclipse wants to have the fastest tool\n> > on earth, so \"java-invoking-C is slower than pure java\" is not a great excuse\n> > either...\n> \n> Note that it's also not true. At least if you use the gcj-specific CNI\n> mechanisms instead of Sun's braindead JNI.\n> \n> \n\nWhat I actually claimed (contrary to Diego's misquote) is that\n\"Java-invokes-C-executable\" would be slower than pure-Java. I didn't\nmake a claim one way or the other about the performance of a Java\nimplementation invoking some form of native interface.\n\njon.\n-- \nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"},{"id":"3042","messageId":"4281EAB5.3020006@peralex.com","threadId":"558","inReplyTo":"2cfc40320505100800426d38ca@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"Noel Grandin","fromEmail":"noel@peralex.com","sentAt":"2005-05-11T11:21:25Z","receivedAt":"2005-05-11T11:21:25Z","isPatch":false,"sender":{"key":"noel@peralex.com","avatar":null},"body":"Hi\n\nNote that eclipse in particular has a fairly complicated repository \nprovider interface.\nThe subversion plugin developers (the subclipse project) took quite a \nwhile to implement their stuff.\nBasing your stuff off of their code would be a good idea.\n\nAlso, they worked in 2 stages - in the first stage, they created \nsomething called the JavaHL interface, behind which they talked to the \nsubversion C libraries using JNI.\nThen they created a pure-java implemenation of the subversion C \nlibraries which also implemented the JavaHL interface, allowing them to \ncompare and contrast the behaviour.\n\nRegards,\n Noel Grandin\n\n\nJon Seymour wrote:\n\n>I have been experimenting with pure-Java implementation of GIT\n>concepts with a goal of eventually providing plugins to Eclipse to\n>allow the Eclipse GUI to interact with GIT repositories.\n>\n>One thing I noticed when doing this is that the present index/cache\n>structure is rather arbitrary and the optimum index structure is\n>determined by the structure of the tools that use a GIT repository\n>rather than the structure of the GIT repository itself.\n>\n>To give a concrete example: the cache currently contains most of the\n>posix stat structure primarily to allow quick change detection. In the\n>Java world, most of the posix stat structure is not directly\n>accessible via the pure-Java file system abstractions. However, for\n>most purposes detecting changes to files modification time and file\n>size would be enough. Given this is the case, a Java-GIT client\n>doesn't need to bother getting access to a posix stat structure and\n>could therefore get away with a simpler index structure, provided it\n>doesn't need to interoperate with a 'C'-GIT client that shared the\n>same workspace. A Java-GIT client might also choose to represent an\n>index cache as a complex serialized Java object graph or (perhaps) an\n>XML document.\n>\n>Another example: I can imagine a variant of the index file structure\n>that recorded all the parents which have been merged into the cache\n>and automatically include this information when performing the commit.\n>\n>The point is that many different index file structures are possible\n>and will be determined in part by the tooling created in the porcelain\n>layer - there really is no one true index file format as there is a\n>one true repository format. Different tools can use different index\n>file formats and still interoperate at the repository level because\n>only the repository format needs to have a solid, unchanging\n>definition.\n>\n>Currently the GIT stack is structured as follows:\n>\n>cogito\n>git-core \n>\n>I think it would be worthwhile if care was taken to draw a distinction\n>between the repository and the cache aspects of the git core, perhaps\n>even going to the extreme of moving all knowledge of the cache into\n>cogito itself. By clearly drawing this distinction, we will more\n>easily enable the creation of different kind of tools sets atop the\n>foundation of the GIT repository format.\n>\n>e.g., either:\n>\n>cogito\n>git-cache\n>git-respository\n>\n>or:\n>\n>cogito-tools\n>cogito-cache\n>git-repository\n>\n>Anyway, I offer this as food for thought - chew or flame away as appropriate!\n>\n>jon.\n> \n>\n\n\nNOTICE: Please note that this email, and the contents thereof, \nare subject to the standard Peralex email disclaimer, which may \nbe found at: http://www.peralex.com/disclaimer.html\n\nIf you cannot access the disclaimer through the URL attached \n and you wish to receive a copy thereof please send \n an email to email@peralex.com\n"},{"id":"3049","messageId":"2cfc4032050511074038d66089@mail.gmail.com","threadId":"558","inReplyTo":"4281EAB5.3020006@peralex.com","subject":"Re: Core and Not-So Core","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-11T14:40:59Z","receivedAt":"2005-05-11T14:40:59Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 5/11/05, Noel Grandin wrote:\n> Hi\n> \n> Note that eclipse in particular has a fairly complicated repository\n> provider interface.\n> The subversion plugin developers (the subclipse project) took quite a\n> while to implement their stuff.\n> Basing your stuff off of their code would be a good idea.\n> \n\nNoel,\n\nThanks for the info. I'll certainly have a look at what the subclipse\nfolks did as I am sure it will be helpful to understand the strategy. \nI do think we are in a slightly different situation here as we don't\nquite have a stable library interface to git yet - Brad Roberts work\nnotwithstanding.\n\nThe repository API in pure Java is almost a no-brainer since Linus has\ndone such a good job in keeping the repository specification simple\nand unambiguous.\n\nA Java workspace API can take advantage of the abstraction and GUI\nfacilities that Java and Eclipse afford so will naturally be different\nin form to the existing command line tools for manipulating the git\nindex. Certainly, there will be similarities - aspects of the 3-way\nmerge, for example, but there will be differences too - workspace\nchange detection will be somewhat assisted by the change notification\nframework in Eclipse and won't require as much manual intervention.\n\n> Also, they worked in 2 stages - in the first stage, they created\n> something called the JavaHL interface, behind which they talked to the\n> subversion C libraries using JNI.\n> Then they created a pure-java implemenation of the subversion C\n> libraries which also implemented the JavaHL interface, allowing them to\n> compare and contrast the behaviour.\n> \n\nAt this stage, my thoughts are to implement a listener pattern to keep\nthe git index up to date, and I may well implement that by calling out\nthe the C git-update-cache executable. This can run in a background\nthread so it needn't be a huge drag on interactive user performance.\n\nAnyway, thanks for your input.\n\njon.\n"},{"id":"3052","messageId":"Pine.LNX.4.21.0505111235030.30848-100000@iabervon.org","threadId":"558","inReplyTo":"2cfc403205051016205d722f23@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-05-11T16:45:21Z","receivedAt":"2005-05-11T16:45:21Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 11 May 2005, Jon Seymour wrote:\n\n> The repository API would contain functionality equivalent to cat-file,\n> ls-tree, most of fsck-cache, rev-list, rev-tree, diff-tree, most of\n> the transport code - things that don't involve use of the index.\n> \n> The workspace API would contain read-tree, write-tree, commit-tree,\n> etc - things that do involve use of the the index.\n\nUnfortunately for this idea, you can't actually check files into or out of\nthe repository using the git tools without the index (in memory at least,\nif not on disk). This is a bit like having a libc with all the system\ncalls except read and write. Sure, there are a number of programs that\nwould be fine that way, but it makes the API unintuitive, and most serious\nprograms need the extension anyway.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"3062","messageId":"2cfc403205051114096117e62f@mail.gmail.com","threadId":"558","inReplyTo":"2cfc403205051114087d283279@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-11T21:09:38Z","receivedAt":"2005-05-11T21:09:38Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 5/12/05, Daniel Barkalow wrote:\n> On Wed, 11 May 2005, Jon Seymour wrote:\n>\n> > The repository API would contain functionality equivalent to cat-file,\n> > ls-tree, most of fsck-cache, rev-list, rev-tree, diff-tree, most of\n> > the transport code - things that don't involve use of the index.\n> >\n> > The workspace API would contain read-tree, write-tree, commit-tree,\n> > etc - things that do involve use of the the index.\n>\n> Unfortunately for this idea, you can't actually check files into or out of\n> the repository using the git tools without the index (in memory at least,\n> if not on disk). This is a bit like having a libc with all the system\n> calls except read and write. Sure, there are a number of programs that\n> would be fine that way, but it makes the API unintuitive, and most serious\n> programs need the extension anyway.\n>\n\nDaniel,\n\nChecking in/checking out is definitely a workspace API function that\ninvolves an index (almost certainly) an on-disk index, but reading and\nwriting from and to the repository is purely a repository API\nfunction.\n\nThere is no reason why the workspace API can't make use of\n\"lower-level\" functions in the repository API. I guess I would argue\nthat the repository API really shouldn't need much, if any knowledge,\nof the workspace API.\n\nThe repository API knows about the on-disk structure of repository\nobjects - it knows how to write writing compressed, SHA1 signed\nobjects, it also knows how to pack and unpack the various object types\nfrom their on-disk representation into structures manipulated by the\nworkspace API.\n\nOn the otherhand the workspace API knows about managing index\n(workspace) state. It knows how to determine whether the\npre-conditions for a commit have been reached. It knows how to read\nthe workspace structures and coordinate read and writes from and to\nthe repository.\n\nI really don't think this makes the API unintuitive, but then I don't\nreally understand why you think this is the case.\n\njon.\n--\nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com\n"},{"id":"3507","messageId":"7i8y2cz8kb.fsf@lanthane.pps.jussieu.fr","threadId":"558","inReplyTo":"2cfc40320505100800426d38ca@mail.gmail.com","subject":"Re: Core and Not-So Core","fromName":"Juliusz Chroboczek","fromEmail":"juliusz.chroboczek@pps.jussieu.fr","sentAt":"2005-05-18T18:35:16Z","receivedAt":"2005-05-18T18:35:16Z","isPatch":false,"sender":{"key":"juliusz.chroboczek@pps.jussieu.fr","avatar":null},"body":"> To give a concrete example: the cache currently contains most of the\n> posix stat structure primarily to allow quick change detection. In the\n> Java world, most of the posix stat structure is not directly\n> accessible via the pure-Java file system abstractions. However, for\n> most purposes detecting changes to files modification time and file\n> size would be enough.\n\nI've got exactly this problem in Darcs-git; and I ignore all of the\ncached data except the file size, mtime and sha1. I don't currently\never write to the cache.\n\n> I think it would be worthwhile if care was taken to draw a distinction\n> between the repository and the cache aspects of the git core, perhaps\n> even going to the extreme of moving all knowledge of the cache into\n> cogito itself.\n\nThere's nothing that prevents you from ignoring the Git cache and\nusing your own cache instead.\n\n Juliusz\n\n"}]}