{"thread":{"id":"18742","subject":"The EGIT Chronicles Issue Volume 3, Issue 1","startedAt":"2009-04-06T06:33:27Z","lastAt":"2009-04-06T15:03:48Z","messageCount":2,"participants":["Robin Rosenberg","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"110527","messageId":"200904060833.27711.robin.rosenberg.lists@dewire.com","threadId":"18742","inReplyTo":null,"subject":"The EGIT Chronicles Issue Volume 3, Issue 1","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2009-04-06T06:33:27Z","receivedAt":"2009-04-06T06:33:27Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"\nA year and a thousand commits has passed since the previous issue of this\nnewsletter.\n\nPublicity\n- The EGit plugin has passed version 0.4 some 280 commits ago and has raised    more attention. Downloads are on the rise and the project gets attention in blogs around the net. mostly positive, which may be surprising, since it still lacks a lot of functionality. That's encouraging.\n\nMost interestingly, some Eclipse developers, i.e. the ones that build and contribute to the Eclipse platform, have raised interest in Git for source control. We have had an Eclipse proposal under development for a while and finally submitted EGit for consideration as and Eclipse Technology project.  Link: http://www.eclipse.org/proposals/egit/\n\nEgit is EPL and BSD licensed which license-wise qualifies it for inclusion into the Eclipse project, unlike the nearest competitor Mercurial that cannot\nbe bundled with Eclipse due to the GPL.\n\nObviously a proposal is not the same thing as acceptance. If you are interested in the project you can contribute to the discussion in the newsgroup available via the link above.\n\n- Shawn's been working on Gerrit2, a code review system built on top of JGit, the core of the Eclipse plugin. \n\nNoteable contributions\n\n- Last Google Summer of Code contributed push/fetch support to the plugin. Marek Zawirskis code is still mostly as he left it, which proves it was well crafted.\n\n- Tor Arne Westbø rewrote the decorator to run faster and wit fewer bugs.\n\nThanks to a dozen or so other people that contributed with important fixes\nand improvements.\n\nThe pipe\n- Lots of stuff is coming. For example, a few diff engines are being considered, a blame implementation has been demonstrated, though not fully ready yet. Some simple merge/cherry picking capability is included already, but without the diff/patch engine it's not as fully automated as one might want yet. Gerrit2 uses it though.\n\nUpdate site\n- New built versions are regularly published to an update site for easy installation.\n- When downloading from the update site, the plugin now has a description you can read (git shortlog) summarizing the changes since the previous version.\n\nBug tracker/Wiki\n- Bugs can be reported on http://egit.googlecode.com and there is a wiki too\n\n- Msysgit issues\nA lot of people choose (?) to run Git and Eclipse on Windows and there are some issues when using the plugin and msysgit side-by-side (and you still have to for serious git use) on Windows. A serious bug was found and fixed in msysgit. That was easily trigged by running Eclipse and msysgit in parallel. During repack your repo could ( likely) be whacked and obliterated. This was fixed in version 1.6.2. There are other issue, but they are very minor compared to this one. All these issues aren't really specific to EGit, but it tends to trigger the problems more often since it accesses the repository quite often to look for changes.\n\n- Controversial topics\nNon-ASCII filenames is an issue that comes up ever more often. JGit/EGit handles this differently since the C Git way simply doesn't work cross platform. Hopefully we'll be able to reconciliate soon. EGit / C Git is compatible between Unix (except OS X) in UTF-8 mode and Windows. For other situations your mileage may vary. We store names in UTF-8 on all platforms. The OSX issue here is the infamous case of decomposed Unicode, i.e. a letter lika ä gets decomposed into two unicode code points on Macs. The final word on this issue has not yet been uttered. \n\n-- robin\n"},{"id":"110592","messageId":"20090406150348.GH23604@spearce.org","threadId":"18742","inReplyTo":"200904060833.27711.robin.rosenberg.lists@dewire.com","subject":"Re: The EGIT Chronicles Issue Volume 3, Issue 1","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-04-06T15:03:48Z","receivedAt":"2009-04-06T15:03:48Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:\n>\n> Most interestingly, some Eclipse developers, i.e. the ones\n> that build and contribute to the Eclipse platform, have raised\n> interest in Git for source control. We have had an Eclipse\n> proposal under development for a while and finally submitted\n> EGit for consideration as and Eclipse Technology project.  Link:\n> http://www.eclipse.org/proposals/egit/\n> \n> Egit is EPL and BSD licensed which license-wise qualifies it for\n> inclusion into the Eclipse project, unlike the nearest competitor\n> Mercurial that cannot be bundled with Eclipse due to the GPL.\n\nFor pretty much this reason alone, Eclipse is starting to consider\nswitching from CVS and SVN to Git.  Some committers were interested\nin a switch to Mecurial, but the GPL license makes it unfriendly\nto the project's distribution rules.\n\n> - Shawn's been working on Gerrit2, a code review system built on\n> top of JGit, the core of the Eclipse plugin.\n\nIts also sucking up all of my time.\n\nBut... its open source, and is gaining (some) momentum in Git\ncommunities that want mandatory code review, but who also want to\navoid the bottleneck of a maintainer / \"merge monkey\".\n\nJunio made some remark back when I joined Google that Google just\nswallows up open source developers whole, and you never hear from\nthem again.  At least half true.  Fortunately I am at least able to\nopen source (EPL if in EGit, BSD if in JGit, else APLv2) everything\nthat I do while in that big black hole known as Google.\n\n> - Lots of stuff is coming. For example, a few diff engines are\n> being considered, a blame implementation has been demonstrated,\n> though not fully ready yet. Some simple merge/cherry picking\n> capability is included already, but without the diff/patch engine\n> it's not as fully automated as one might want yet. Gerrit2 uses\n> it though.\n\nThe lack of a diff engine is starting to become an issue for me\nin Gerrit2.  Maybe next month I'll be able to get to it, if someone\ndoesn't beat me to it first.  Gerrit2 users are asking for proper\ncherry pick support, not just the path-level-only cr*p we do now.\n\n-- \nShawn.\n"}]}