threads / discuss / 18742

The EGIT Chronicles Issue Volume 3, Issue 1

Subject: The EGIT Chronicles Issue Volume 3, Issue 1

## tl;dr

2 messages between Apr 6, 2009 and Apr 6, 2009.

replies: 1people: 2as markdown or json

Robin Rosenberg· Apr 6, 2009, 06:33 UTC · lore

A year and a thousand commits has passed since the previous issue of this newsletter.

Publicity
- 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.
Most 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/

Egit is EPL and BSD licensed which license-wise qualifies it for inclusion into the Eclipse project, unlike the nearest competitor Mercurial that cannot be bundled with Eclipse due to the GPL.

Obviously 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.
- Shawn's been working on Gerrit2, a code review system built on top of JGit, the core of the Eclipse plugin. 
Noteable contributions
- 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.
- Tor Arne Westbø rewrote the decorator to run faster and wit fewer bugs.

Thanks to a dozen or so other people that contributed with important fixes and improvements.

The pipe
- 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.
Update site
- New built versions are regularly published to an update site for easy installation.
- When downloading from the update site, the plugin now has a description you can read (git shortlog) summarizing the changes since the previous version.
Bug tracker/Wiki
- Bugs can be reported on http://egit.googlecode.com and there is a wiki too
- Msysgit issues
A 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.
- Controversial topics
Non-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. 
-- robin
Shawn O. Pearce· Apr 6, 2009, 15:03 UTC · re: Robin Rosenberg · lore

Re: The EGIT Chronicles Issue Volume 3, Issue 1

Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
Show 11 quoted lines
>
> Most 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/
> 
> Egit is EPL and BSD licensed which license-wise qualifies it for
> inclusion into the Eclipse project, unlike the nearest competitor
> Mercurial that cannot be bundled with Eclipse due to the GPL.

For pretty much this reason alone, Eclipse is starting to consider switching from CVS and SVN to Git. Some committers were interested in a switch to Mecurial, but the GPL license makes it unfriendly to the project's distribution rules.

> - Shawn's been working on Gerrit2, a code review system built on
> top of JGit, the core of the Eclipse plugin.
Its also sucking up all of my time.

But... its open source, and is gaining (some) momentum in Git communities that want mandatory code review, but who also want to avoid the bottleneck of a maintainer / "merge monkey".

Junio made some remark back when I joined Google that Google just swallows up open source developers whole, and you never hear from them again. At least half true. Fortunately I am at least able to open source (EPL if in EGit, BSD if in JGit, else APLv2) everything that I do while in that big black hole known as Google.

Show 6 quoted lines
> - 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.

The lack of a diff engine is starting to become an issue for me in Gerrit2. Maybe next month I'll be able to get to it, if someone doesn't beat me to it first. Gerrit2 users are asking for proper cherry pick support, not just the path-level-only cr*p we do now.

-- 
Shawn.

← back to recent threads