Dariusz Łuksza

This is a next opportunity for all persons that understood polish to hear a little bit about EGit and git-connected-software. This time I’ll be speaking at Warsjawa conference, more information about it can be found at warsjawa.pl.

Because of time limitation I’ll only cover EGit and connected software like  gerrit, I’ll skip the git introduction part, but will try to give some quick overview about it during presentation. I think that this is a good opportunity to get familiar with some ideas of distributed version control systems.

Actually this is quite old feature because it is available in nightly builds since two or more weeks. But I think that is worth mention, because it give a possibility to review current index and working tree status at the same time.

To activate this feature simply mark “Include local uncommited changes in comparison” in synchronize dialog and all staged and changed files will be shown in Synchronize view.

On 28th of October I’ll be giving presentation about EGit 0.10 0.9 (and Git in general) on Szczecin JUG meeting. The official announcement can be found on Szczecin’s JUG mailing list (it’s in polish).

This would be my second presentation (first one was at Poznań Eclipse DemoCamp) and it will be quite similar to first one, since they all covers the same topic . Of course it will cover new features of 0.10 0.9 release.

So if you would be near by and would like to hear about EGit in polish feel free to join us

According to this post of Christian Halstrick and those two commits: 1 2. The upcoming version of JGit and EGit would have merge support! The previous stable version (0.8) had only support for fast-forward merge; all non fast-forward merges must be done using CGit, now all kinds of merge can be done using EGit UI.

The 0.9 version would have more cool features eg. History view improvements, branch and tag dialog improvements and (of course) support for Synchronize view. Say tuned for a full list of new and noteworthy that will be published in upcoming days.

Finally! I’ve implemented ChangeSet support in EGit! It looks almost the same as I was imagine it before I’ve started coding. The reality and Team API turn out much more complicated then I was thinking of it before Summer Of Code. But hours days of debugging and analyzing code of Team Framework, CVS integration plugin and “Example FileSystem” project finally give me some reasonable results. Apart from code analysis I’ve implemented four or five (I’ve published only two of them 1, 2) different approaches for this problem, all of them had some weakens and issues that latest implementation seams to solve. But now it is unimportant, the most important thing right now is to get this feature merged into EGit as fast as it is possible, another important thing is … the feature list!

Current implementation shows Git Change Set next to “normal change set”. In my humble opinion this should be changed in the feature; Git Change Set view should be set as default view for synchronization for git, because in git we track changes on repository level and cannot import only part of commit. Above Git Change Set we have node that represent repository, if we launch synchronization for more then one repository there would be more nodes on this level. Inside repository node we have list of commits that occurs between two selected points (branches of versions). Every commit is described by text label with contains first 6 characters from commit SHA-1 and first line of commit message. Commits are sorted chronologically, most recent commits are on the top. Inside commit we have list of changes that are associated with this commit. Double click action on file element will launch ChangeEditor window with will display changes that were made between two most recent commits (this one and it parent).

Here is a screenshot how it looks in real world:

It shows list of changes between current HEAD and tag v0.8.4 … from height of scrollbar in Synchronize window we can guess that upcoming 0.9.0 release will contain lots of cool new features and bug fixes ;>

Currently I didn’t manage display change direction (does it is incoming, outgoing or conflicting) I’ll work on that in nearest feature. Another think that I was unable to achieve is “proper resource handling” eg. displaying java packages as this JDT does, to be honest I don’t know that this is achievable but I’ll try … dome day . Next think is context menu and merge/commit/overwrite actions, for now didn’t even think about it, but it also should be done in nearest feature.

What is your opinion about this new feature? Maybe you see something that should be changed, removed or improved? Please, let me know … feedback is strongly appreciated!

About 48 hours ago I was describing my first small step to get ChangeSet implemented. Two days is a lots of time, and current status of this feature can be described by this screen shot:

As you can see, the “Git Change Set” appears next to the standard change set representation, this can be changed using third tool bar button (from left hand side).

Currently list of commits contains only commits between base and destination rev, the common ancestor isn’t included or even dispatched by the change set implementation (this can, or even should, be changed). Also there should be included proper graphical representations for commits, folders and files; additionally compare view should be launched when we double click on file. That things should be improved/fixed before I’ll publish code.

Beside that small issues I think that right now it is the best time to start discussion how we (yes, me and you!) would like to use this feature and have it should behave and and look. What you can see in above screen shot is only my proposition and (as always) I’m open for any suggestions and ideas. The best place for this discussion is Eclispe’s Bugzilla and bug 318473, and I encourage you to share yours opinion with us!

I’m looking forward for any feedback about this feature

BTW. One of thins that I’m proud of, in current implementation, is that I haven’t use any kind of internal API of Team Framework ;>

This is  actually a really small step, because I only manage to display list of commits between two selected branches/tags (as you can see on this screen shot):

But for me it is a great success, after more then a week of fighting with Team Framework API, with was actually designed for centralized version control system.

Actually this list isn’t even sorted properly, listed commits doesn’t contains any data/child  … but I think that right now things should goes faster then it was before, because I think that I’ve got idea of change set’s.

What should be done? All commit’s should be assigned to root node with should represent repository (this is in  case if someone will be synchronizing multiple repositories at a same time). Commit’s should contains list of changes with proper path representation: project (if it is included in this repository), folder (and java packages if it is a java project) and finally files that was changed in this particular commit.

First step of providing synchronization feature into  EGit was, display set of changes between two branches, and this works quite well (if there is applied my latest patch for common ancestor).

The next step of integration would be to make it more “git” way. In this case all changes should be spited into proper commits, because in Git we track changes on repository level (not on file level) and every commit leads us from one consistent state to another. In this case, synchronize view should show list of commits (first 4-6 characters of each SHA-1 and first line from commit message), then as a child of particular commit we should see resources that was changed by this commit. Generally all changes in particular commit should have one direction incoming or outgoing (despite conflicts that can appears on file or container level inside commit). Also merge operation should be available only on commit level.

OK, so this is how things should be handled and how they should look like … but how to achieve it?

This is quite tricky question. Thanks of bug 317934 that was made by Benjamin Muskalla I’ve started for looking information about ‘change set’ in eclipse.This leads me to ‘Team Logical Model Integration‘. According to this documentation I should almost rewrite all project … change base class of GitSynchronizationParticipant, provides implementation of IResourceMapping, ISynchornizationContext, IResourceMappingManager, etc …

The other thing that I’ve spot some time ago, is that Mercurial plug-in for Eclipse has functionally that is somehow similar with those that I’ve want to implement (they split changes into two groups: incoming and outgoing); thank god that it is open sourced . With base knowledge about ‘Eclipse Logical Model’ I’ve downloaded MercurialEclipse sources … of course using hg BTW. to download sources I was forced to create an account on javaforge.com … this is next account that I used only once … no comments for that …

When I finally get sources I’ve started inspecting how they implement change sets … and realize that they also use ‘Logical Model Integration’ … but according to comment for MercurialSynchronizeParticipant they don’t really know why they use ModelSynchronizeParticipant … why bother with that, so it is working .

So my plan for next few days is:

• migrate actual implementation of synchronization on ‘Logical Model’
• implement change sets

This looks like there will be next 1 or 2 kloc patch set o integrate into EGit …

Wish me luck … or suggest better/easier solution

Any suggestions are strongly required

I don’t know exactly when we hit a Google Summer of Code 2010 midterm date … time runs so fast, few weeks ago I was writing that I’ve got accepted in this year’s program edition, and now we hit a midterm evaluations. This is a quite good time to sum up this short period of time.

Starting from the begging … estimating a project; now I know that initially I was very, very (and even more very, very ) optimistic about project time line. According to my initial estimation I should now start working on stashing support in JGit … but for now I’m “stuck” in synchronize view. Even more because now I see that I’ll need two or more weeks to make it ready for 0.9.0 release, now it has two major issues that I would like to solve before upcoming release. I even  don’t want to think where I would be right now if Remy didn’t made initial contribution …

OK, so what is project current status? Well we had an synchronize action and it works quite well. It shows upcoming, outgoing and conflicting changes … but there are few issues in current implementation. First of all common ancestor isn’t calculated properly (according to bug: 317371). Next issue is that we always use HEAD as a ‘local’ in three-way-compare, to be honest this seams to be an Team Framework limitation because ‘local’ is always instance of IResource .. btw. I should raise an issue for this . Last thing (for now) that in my humble opinion should be included in 0.9.0 is support for change set’s (bug: 3318473) because Git works on repository state changes not on file changes. Additionally there is one small feature that also should be included in 0.9.0: merging support from synchronization view, but (for now) it seams to be a simple thing to achieve.

What are my plans? Fix for bug 317371 currently wait for approvement in Gerrit, so I thing that this is rather a closed thing. For now I’ll focus on change set support. In case of popper handling of source branch setup I’ll wait for any hints on eclipse forum thread, then I thin that I’ll try to implement it somehow. If I fail in this task, I thing that we should disable source branch selecting and set it by default to HEAD.

Some statistics and numbers:

• Add preliminary synchronization support within Eclipse for branches. – based on Remy Suen work
  32 files changed, 2902 insertions(+), 10 deletions(-)
• Refactored UI tests
  15 files changed, 434 insertions(+), 393 deletions(-)
• Fixes strange result set in Synchronize view on Windows
  1 files changed, 26 insertions(+), 19 deletions(-)
• Fix NPE when deleting project used in Synchronize View
  1 files changed, 14 insertions(+), 8 deletions(-)
• Show repository path in Synchronize View
  4 files changed, 14 insertions(+), 6 deletions(-)
• Simplify API of GitSynchronizeData class.
  5 files changed, 33 insertions(+), 72 deletions(-)
• Prevent from NullPointerException’s
  2 files changed, 24 insertions(+), 8 deletions(-)
• Add tests for integration with Synchronize view
  13 files changed, 2249 insertions(+), 12 deletions(-)
• Fixes obtaining common ancestor in Synchronize view – wait for code review
  22 files changed, 1499 insertions(+), 1329 deletions(-)

In my humble opinion this is quite good result for around 7 weeks of work

Yesterday  patch “Add preliminary synchronization support within Eclipse for branches” (to be honest it also supports synchronization with tags) was merged into master. What it means ? This mean that every one who want to play with current Synchronization view support in EGit can easily download it from EGit’s nightly build repository.

Quick description what is supported you can find in my previous post. Of course you can play with other new features like reimplemented Git Repositories view, colorize diff and others … detailed description can be found here

Please be aware that this is only a “preliminary synchronization support“. This means that there are some things to work on and to be added in nearest feature. In case of any bugs or feature request please fill a bug report for EGit.