Twitter github

Posts Tagged with “eclipse”

September 23, 2013
Comments Closed

Gerrit Code Review Book

By

It’s great to finally see a book out there on Gerrit Code Review. First off, it’s amazing that the cover features the Gerrit mascot which is the kung fu review cuckoo…

As some of you may know, I’m a huge fan of Gerrit and was involved with enabling it for Eclipse Foundation projects as part of our great Git migration. I also shamelessly support pretty much anything else that embeds JGit.

Anyways, I spent some time last weekend going through the book and I found it did a great job introducing Gerrit while taking care of basic setup gotchas. If you’re interested in using Gerrit at the Eclipse Foundation (or else where) and have no idea what the hubbub is about, I highly recommend checking the book out. As an advanced Gerrit user, I found the Appendix sections on working with GitHub (Gerrit supports replication) and integration with Jenkins (or Hudson) well done. As a bonus, I also learned about GerritHub which I had no idea existed.

In my opinion, the main downside of the book is that it didn’t cover an advanced Gerrit feature regarding tweaking submit rules with Prolog (which could always use more documentation), however, you can check out the online docs for some solid examples.

In the end, it’s always good to support authors who take the time to write about open source technology. Check the book out!

February 21, 2013
No Comments

EGit and JGit 2.3 Released

By

The JGit and EGit teams are happy to announce the 2.3.1 release.

What’s new? I recommend checking out the JGit New and Noteworthy along with the EGit New and Noteworthy documents. The team is excited to get a new version ready for the Juno SR2 release. The release tag is: 2.3.1.201302201838-r

You can download the latest release using this repository (or the Eclipse Marketplace): http://download.eclipse.org/egit/updates-2.3

Enjoy and the next release will be in time for Kepler in June 2013. I personally look forward to recursive merge support soon (see bug 380314).

January 28, 2013
Comments Closed

Poll: Help name the 2014 Eclipse Release

By

There will be an Eclipse Simultaneous Release on the fourth Wednesday of June 2014. We just started the poll for potential release names (see bug 398191) based on eclipse.org community feedback. The potential names are:

Note that this community poll will be used to pick top choice. We may have a series of run-off polls with voting until majority consensus achieved. The poll will be opened for a week and then I expect the final decision on the name will be made by Feb 15th at the latest (after Eclipse Legal approval is finalized).

Go vote and be heard!

January 15, 2013
No Comments

Eclipse: Naming Kepler+1

By

It’s that time of year again, time to name the next Eclipse release. The Eclipse Kepler release will happen on June 26, 2013, but after that, we’ll need a new name for the following release (because calling the next release Kepler+1 gets awkward over time). The naming responsibilities traditionally fall to the Eclipse Planning Council and preference will be given to names that start with “L”, but no strict rule that other names would not be considered. On top of that, preference is given to names that fit the moon, heavenly body gods, or scientists themes we’ve had in the past years.

To add your name to the list of possible names, see bug 398191. Here’s an initial list of names to get your creative juices flowing:

  • Lacus
  • Lakshmi
  • Leto
  • Leo
  • Leda
  • Loge
  • Lok
  • Luna

Have fun, the bugzilla entry will remain open until January 22nd to gather suggestions for potential names. After that, a community poll will be used to pick top choice. We may have a series of run-off polls until a majority vote is achieved. The poll should be opened on January 22nd with a week of voting allowed. The final decision on the name will be made by Feb 15th at the latest, maybe earlier depending how quickly final Legal approval is.

December 21, 2012
2 Comments

Eclipse Foundation Migrated to Git

By

Update: Mike Milinkovich has a great post on this topic too!

The countdown is finally over…

 

Over 80% of the projects at the Eclipse Foundation are finally on Git and CVS access is switched to be read only. I believe the projects left on SVN will migrate soon enough, there are just too many advantages with using Git.

One interesting bit of history regarding this migration to Git is it all started back in 2009 when some community and Eclipse Foundation board members wanted to have Git, JGit and EGit all at Eclipse. You may not believe it, but at that time, moving to Git was a bit controversial. I dug up a old Google doc that we had discussing the pros and cons of moving to Git (prepping a presentation for the Board), this is what we had for benefits:

  • Committers want Git support on eclipse.org
  • Provides all contributors equal tool support: non-committers equal citizens, reduces contributor startup time; have all committer tools at start, reduces contributor -> committer conversion bump
  • More accurate recording of activity: author recorded separately from committer; better IP tracking, code movement detection; better IP tracking after-the-fact; easy to maintain history, audit trails
  • Open source implementations; meets mandate to avoid vendor lock-in.
  • Widely popular: github.com has become very high traffic site.
  • Staying power; many large projects use Git, its not going away. Big current users: Qt, KDE, Linux, Android, X.org, Wine, OLPC, OpenAFS, Ruby, Perl5. More considering: GNOME, ASF
  • Easier to move projects to eclipse.org

An entertaining part of this analysis was the mention of GitHub becoming a high traffic site in 2009… GitHub recently posted some stats so we have an idea of what life was like in 2009 compared to now…

GitHub Stats

How times change.

December 20, 2012
No Comments

EGit and JGit 2.2 Released

By

The JGit and EGit teams are happy to announce the 2.2 release.

What’s new? I recommend checking out the JGit New and Noteworthy along with the EGit New and Noteworthy documents. While there were a lot of new features, my favorite feature is the performance improvement in EGit for re-indexing repositories (it’s now done incrementally, see bug 393642).

The release tag is: 2.2.0.201212191850-r

You can download the latest release using this repository: http://download.eclipse.org/egit/updates

Enjoy and happy holidays! The next release will be in mid February.

October 9, 2012
No Comments

Checkout GitHub Pull Requests via CLI

By

The Eclipse Foundation (by the way, you can follow them on Twitter now at @EclipseFdn) is now looking at ways to make it easier to accept GitHub pull requests. I highly recommend you check out this bug if you have any comments on the issue. I think there’s a lot we can do to make the lives of eclipse.org committers easier, along with our community contributors.

Ok, back to the main point of this post. I found a neat trick recently when it comes to accessing GitHub pull requests via the command line. The traditional way is adding a remote that involves the persons repository issuing the pull request (or curling a .patch file via curl https://github.com/repo/pull/123.patch and piping it to git-am). However, it’s as simple as modifying your fetch parameters for the origin repository to include “+refs/pull/*/head:refs/remotes/origin/pr/*” as an option. You can set this optional globally if you like in your git-config as a bonus:

git config --add remote.origin.fetch "+refs/pull/*/head:refs/remotes/origin/pr/*"

You are now able to easily fetch and checkout pull requests to play with. For example:

$ git checkout pr/123
Branch pr/123 set up to track remote branch pr/123 from origin.
Switched to a new branch 'pr/123'

That’s my git tip (or hack) for today, hope you enjoy it!

September 26, 2012
No Comments

EGit and JGit 2.1 Released

By

The EGit and JGit teams are proud to announce the 2.1 release in time for Juno SR1.

The precise release version is 2.1.0.201209190230-r

This release contains some nice performance gains, improved autoCRLF support and the ability to optionally combine the commit and push to upstream steps in the Commit dialog (see EGit New and Noteworthy for the full list of features). JGit now provides an implementation for git-gc for FileRepositories (see JGit New and Noteworthy for the full list).

On a related note, I recently added BouncyCastle 1.47 to Orbit (see bug 390058). It was a long journey, but it will enable the JGit team to add support for signed commits and tags (see bugs 386908 and 382212).

Enjoy the latest release!

September 11, 2012
Comments Closed

100 Days: Eclipse Foundation Moves to Git

By

It’s great to see over 60% of Eclipse Foundation projects already migrated to Git.

It’s more rewarding given that this issue was brought up a couple years ago by a few community members (who were called a bit crazy at the time). It’s nice to see things finally through though, I think most people would agree that moving to Git was the right thing to do to modernize our infrastructure.

There are now 100 days until CVS becomes read only and is retired. If you’re an Eclipse Foundation project, I highly recommend migrating to Git. If you’re new to Git, I recommend trying out GitHub’s online tutorial (try.github.com) and the ProGit book. If you don’t want to migrate your main repositories first, I recommend starting with your project website first.

On a related note, the EGit and JGit projects are gearing up to release 2.1 soon for Juno SR1. Here’s a sneak peak at the release notes and if you want to contribute any changes in for 2.1, you only have a few more days to do so. I personally find the performance improved in the upcoming release for larger projects that I work on. I think we’re getting closer to finally making Ed Merks happy with the tooling, almost there!

June 27, 2012
4 Comments

EGit and JGit 2.0 Released for Juno

By

The EGit and JGit teams are happy to announce the 2.0 release in time for the Eclipse Juno release.

Check out the respective JGit New and Noteworthy and EGit New and Noteworthy documents to see what’s new. In the end, it’s great to see 64% of the projects released on the Juno release to use Git, we’ve come a long way. I’m hoping that after the dust settles from the simultaneous release, the remaining projects can focus on migrating to Git.

For now, enjoy Juno and improved Git tooling support!

« Older Entries
Newer Entries »