Integrating Mylyn into your Git workflow

by Benjamin Muskalla, February 16th, 2011

In January, most of the EGit committers met at the “EGit Summit” in Walldorf, Germany. We had a blast hanging out together, planning the future direction for EGit/JGit, and implementing new features.

Thanks again to the SAP team for hosting the event.

As you can see on the whiteboard, there were numerous ideas suggested by the EGit committers who attended. We organized and prioritized the topics and then broke up into small teams. One user story that was commonly asked for was improved integration between EGit and Mylyn – Chris Aniszczyk (Red Hat), Manuel Doninger (Markant) and I (Tasktop) decided to form a team to make this improved integration real.

“EGit Mylyn (Incubation)”, a new feature that came from our activities at the Summit, allows you to have a tighter integration between Mylyn and EGit. This feature is available from the current update site.

We were fortunate to have a starting point from Manuel and others, and as result, by the end of the first day of the Summit, initial support for pre-populating the commit message from the active task was completed. This means that if you’re activly working on a task, once you fire up the commit dialog, it is prefilled with the commit message for the activated task. See the screenshots below.

The industry analysts like Forrester and Gartner have been emphasizing the importance of visibility and traceability in today’s modern development efforts. One great feature we were able to implement for achieving better traceability is support for linking between commits and tasks. With this feature, once a you fire up the History view of your git project, you’re able to open up the task corresponding to the commit with a single click. We implemented the same feature for the Git Synchronize view as well.

In the future, we want to work on an even tighter integration between EGit and Mylyn. One idea is per-task branching. This essentially means that if you activate a task, EGit automatically creates a “feature branch” for your task and later it will merge it back into the master branch for pushing upstream. Manuel already has a working prototype which will hopefully find its way into the EGit master soon. If you’re interested in this idea, take look at this task.

Besides the Mylyn integration, many other new features and fixes found their way into the 0.11 stream of EGit. You may want to check out the New & Noteworthy.

If you have your own ideas for how EGit and Mylyn can work together more seamlessly, please comment on this post or open a new feature request in the EGit Bugzilla component. We always are excited to get new committers as well as new contributors to EGit who can help us make it an even better project.

15 Responses to “Integrating Mylyn into your Git workflow”

  1. Integrating Mylyn into your Git workflow Says:

    [...] direction for EGit/JGit, and implementing new features. Thanks again to the SAP team for hosting… [full post] Benjamin Muskalla Tasktop Blog eclipsemylynopen source 0 0 0 [...]

  2. Alex Blewitt Says:

    In principle the idea is good, but Mylyn needs to generate git-style messages for it to be useful.

    http://365git.tumblr.com/post/3308646748/writing-git-commit-messages

    The first line needs to be short (50 chars), followed by a blank line, followed by paragraphs flowed to 72 characters.

    The bug state should not be part of the commit, and if there is a bug number, it should be added at the bottom as

    Bug: 12345

  3. Neville Grand Says:

    Mylyn integration is all very nice, but really the EGit committers should focus on fixing the ever-increasing amount of bugs and missing core features. If EGit 1.0 is going to be released in June it will arrive half-baked.

  4. Martin Says:

    mmmm. you could have mentioned that you were sitting in the office nearby. i would have said “hello” :-)

  5. Manuel Doninger Says:

    @Alex: You can edit the Commit message template in Window -> Preferences -> Tasks -> Team. The following template could provide a more or less git-style message:

    ${task.description}

    Bug: ${task.key}

    Then the title of the Mylyn task would be in the first line, after that you can provide your explanations of the commit and the bug id would be in the last line.

  6. Benjamin Muskalla Says:

    @Alex Good point! As Manuel noted, it is possible to do it by hand for now. I think, in addition, we should do this step automatically, e.g. once a project is cloned/shared with EGit and there is no default, we should adapt the template accordingly. Will raise this in Bugzilla and CC you guys.

    @Neville That’s right. We are in fact focusing on getting EGit more stable and get the most out of it. Currenlty we are concentrating on getting the core features done (on the JGit layer), better performance (eg. Synchronize view got a huge performance boost) and better usability (eg. less complex Fetch/Push dialogs). The Mylyn integration on the other side is one of the most requested features from the community and also helps the committers itself to coordinate their efforts and have an improved traceability.

    @Martin Sorry, totally forgot that you’re in the building. Will call you next time I’m visiting SAP :)

  7. James Says:

    I recently stumbled upon this EGit fork that seems to be doing the same thing mentioned in this post:

    http://www.eclipse.org/forums/index.php/mv/tree/201937/

    Are these changes making their way back into the official EGit?

  8. Benjamin Muskalla Says:

    James, very good question! Indeed all the changes mentioned above are already part of the official EGit Release (1.0 and 1.1). I don’t know why Intland decided to fork EGit for these matters. EGit is a very open contributor policy and receives contributions from non-commiters on a daily basis which are integrated into EGits master. I currently don’t see a reason to fork EGit to get new features in.

  9. James Says:

    Thanks Benjamin!

    I’ve got one last question:

    How can I add the current git branch to the default commit message template?

    (I’m accessing this through Window -> Preferences -> Mylyn -> Team.)

  10. Benjamin Muskalla Says:

    > How can I add the current git branch to the default commit message template?

    Good question James. So far, there is no built-in template for the active branch. Thinking about it, this is something we might consider but need to take into account different obstacles (eg. multiple repositories). How about you open a new Feature Request at bugs.eclipse.org describing your scenario? Please add to me the CC list and I’ll have a look at it.

  11. Fabian Schwarzer Says:

    Hi! Is there an overview of all supported placeholders (like ${task.key})?

  12. Benjamin Muskalla Says:

    Fabian,

    when you go to your preferences, Mylyn > Team, you can use the content assist (Ctrl+Space) to see a list of all available templates.

  13. Hob Says:

    Has there been any progress on per-task branching? This is how I do my branching anyway, so having Mylyn do it for me would be a boon. Would be interested in contributing if it’s still in-progress.

  14. Daniel Gske Says:

    WRT feature branches — these are regarded as undesirable by the continuous delivery community. As a kind of poor man’s modular architecture, the need to work on feature branches may indicate something wrong on the basic level of your software architecture. Just a thought.

    Jez Humble of Thoughtworks gave a good talk on the larger topic of continuous delivery at http://www.infoq.com/presentations/Continuous-Delivery and you can view the related slides http://www.slideshare.net/jezhumble/continuous-delivery-5359386

  15. James Says:

    > the need to work on feature branches may indicate something wrong on the basic level of your software architecture.

    On the contrary, I feel that feature branches are quite desirable by the CI & developer community when used as part of a CI workflow.

    I’ve found that feature branches in git are quite useful when organizing, and also for simplifying the merging process for a set of changes that are tied to a user story. Due to the ease of branch creation & merging in Git, they are quick & easy to use for a unit of work (ie: user story). Labeling each feature branch with a story ID can help one to organize and tie a set of changes back into a ticketing system; for example, a branch name might be: OPS-123-fix-some-problem. This can help especially when working on a task which gets blocked for a time, and help one to continue work after switching to work on another task (ie: what was I working on again? How far did I get? What files was I working on?). Branches (especially in git) also help to merge a set of changes (sometimes out of order, or with conflicts to resolve) on a steadily moving mainline codebase. However, Feature branches alone are not very good without some sort of testing or CI process in place to promote or merge them into the mainline. Many feature branches on the “blessed” central repo can become unwieldy and is not recommended. In the fork & pull model, feature branches are generally deleted after merging.

Leave a Reply