Twitter github

Category “work”

EGit and JGit 2.2 Released

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.

Gerrit Tip: Rebase Change Button

I use Gerrit quite often and have a particular workflow… but sometimes I discover new features out of the blue…

Since Gerrit 2.4 (see release notes), a Rebase button was added that will take the most recent patch set and have it be rebased onto the tip of the destination branch or the latest patchset of the change depended upon. A new patch set containing the rebased commit will be produced and added to the change. It’s a great feature which helps alleviate a common workflow when working with Gerrit.

Note: Another option would be to set the Submit Action (via Admin > Projects > [Project Name] > General > Project Options) for your project to use ‘Cherry Pick’ as this would keep a clean history with no merge commits when submitting changes.

Anyways, enjoy and happy rebasing!

Open Compliance Summit Asia 2012

Last month, I was grateful to have the opportunity to present at the Open Compliance Summit hosted by the Linux Foundation.

As some of you may know, a portion of my current job at Twitter is defining our open source strategy and compliance efforts. While at Twitter we’re fortunate that compliance is less burdensome than at some other traditional companies who have many distribution points (e.g., devices), nevertheless it’s still important to respect licenses and the software authors intention. We mostly run on open source software and are cognizant of the benefit we receive from a variety of open source communities and what it means to give back. We also don’t mind sharing what we develop, on top of preferring liberal licenses as that helps with adoption (and also makes compliance less complicated) in my opinion.

At the end of the day, it was a great event bringing together participants from different companies to discuss open source compliance issues and best practices. Thanks again to the Linux Foundation for hosting the event.

Checkout GitHub Pull Requests via CLI

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!

EGit and JGit 2.1 Released

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!

Comments Closed

100 Days: Eclipse Foundation Moves to Git

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!

EGit and JGit 2.0 Released for Juno

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!

Comments Closed

Ecipse Juno Released for “Friends”

Besides finding out that the Eclipse Foundation is finally on Twitter (follow @EclipseFdn), I was greeted with this email this morning regarding the Eclipse Juno release:

It’s available one day early for Friends of Eclipse members who donate to give back a bit to the Eclipse community. If you want to access Eclipse Juno a bit early, consider donating as the money goes to great causes like sponsoring community events and sending students to Eclipse conferences.

Stepping back a moment to reflect on the Eclipse Juno release, it’s amazing to see over 70 projects ship at the same time which results in about 55 million lines of code being delivered.

It’s one of the largest open source releases ever. In my opinion, this is really attributed to the maturity  and professionalism of the Eclipse community. It’s a great feeling to be a small part of this community and of a release this size.

Enjoy!

Comments Closed

The Innovators Patent Agreement

For those of us who work as engineers in the software industry, we may have patented a few things related to software in our careers. Typically, engineers and designers sign an agreement with their company that irrevocably gives that company full control of the patents. The company then can use them however they want, which may include selling them to others who can also use them however they want. These days, there are many non-practicing entities stifling progress, aiming offensive patent lawsuits at software and high-tech companies who are innovating and moving the industry forward. We can do better than this, today at Twitter I’m proud we announced the Innovators Patent Agreement (IPA).

The IPA is a new way to do patent assignment that keeps control in the hands of engineers. It is a commitment from a company to the engineers that patents can only be used for defensive purposes–that is, only in response to a litigation threat against the company or a recent history of offensive patent use. The company will not use the patents in offensive litigation without the permission of the inventors. With the IPA, employees can be assured that their patents will be used only as a shield rather than as a weapon.

We are still in early stages, and have just started to reach out to other companies to discuss IPA and whether it might make sense for them too. We have posted the IPA on Github, with the hope that folks improve the IPA in an open source fashion and share it with their respective companies.

Twitter will implement the IPA later this year, and it will apply to all patents issued to our engineers. If you have comments, feel free to look at the Github repository or join the conversation on Twitter with hashtag #IPA

Travis CI

I’ve been slightly enamored with Travis CI as of late…

For those who don’t know what Travis CI is, it’s a hosted continuous integration service for the open source community, still in alpha stages but surprisingly stable from my point of view. It also integrates nicely with your GitHub account so you can easily decide what projects you want to build by logging in using your GitHub credentials. On top of that, the Travis CI code itself is hosted on GitHub for people to contribute to.

Traditionally, open source projects benefited from having continuous integration service if they were hosted part of an open source foundation, however, Travis CI allows any project to take advantage of the service if they support the language:

For example, I recently decided to add Travis CI support to hogan.js, which is one of Twitter’s open source projects, essentially a compiler for the Mustache templating language. You essentially get a nice build status icon that integrates nicely into your GitHub’s projects README:

Adding Travis CI support for the hogan.js Javascript library was fairly trivial, you can take a peak at the commit to figure out how it was done or read the Travis CI documentation. The only tricky part was ensuring that git submodules were properly initialized and phantomJS was launched so QUnit can successfully run. It’s even easier for other languages that Travis CI supports!

In the end, I love what Travis CI is doing for the open source community and how it integrates with GitHub. Continuous integration is something every software project should have and Travis CI makes it really easy to get started. In a future post, I’ll considering comparing Travis CI to some of the other CI options out there (e.g., Hudson/Jenkins), but for now, consider trying out or even sponsoring the service.