Dariusz Łuksza

So what is “interactive adding” in git? Imagine situation when you change two or three lines in file (this could be also two or three blocks/methods), then you realize that you will want to commit those changes in two (three or more) separate commits.

Here is Al Blue’s description how interactive adding works in native git: Git Tip of the Week: Interactive Adding

What about EGit? Honestly this is currently supported … but it isn’t really straight forward to access. You need to select a file then choose from context menu Team > Compare With > Git Index and then you can easily move changes around, finally when you are happy with both versions (left is working tree and right is one that will be staged/added to index) just save compare editor contents. Version from right hand side will be added to index as it is in this editor.

OK, so now you can easily stage and unstage partial changes … maybe you would also like to partial replace staged changes by version in HEAD? Currently in version 1.1 you can compare version from git index with HEAD version using context menu Team > Compare With > Git Index with HEAD, but you cannot overwrite anything … yet, because (hopefully) in 1.2 such option will be available. Here is patch that adds this functionality (to be honest this is a side effect…).

And what about (my favorite) Synchronize View? Unfortunately EGit 1.1 don’t allow to move any changes in compare editors launched from Synchronize View … but with change mentioned above and with this one both features would be available from Git Commits model (before it was named as Git Change Set model)

Here is a short screen cast that shows how this work:

For last three weeks I was working on including non-workspace files in Workspace presentation model in Synchronize View. This idea can sounds weird since the Workspace presentation model was designed to show only changed files that are in Eclipse workspace … but there are some use cases in which such behavior seams to be reasonable (eg. EGit and JGit projects doesn’t import repository root into workspace only projects are imported and files like master pom.xml, README, LICENCE and so on are left outside workspace).

If you don’t import all data into Eclipse workspace you won’t see any incoming nor outgoing changes. Even more, after merge/rebase actions changes in non-workspace files will magically appear in those resources and can even brake something (eg. massed up in master pom.xml file).

So, what is current status ? First of all I want to point that I’m describing here current situation in my working copy, described here changes currently are not available in public. After hours of debugging, code analysis and rewriting my code I’ve manage to show some indication in synchornize view that there are some non-workspace chagnes. The next step will be to show what particular file was changed and then enable all operations like overwrite, mark as merged, etc.

Here is a screenshot showing current status:

As you can see there is home folder in sync results. It even have expand indicator (but after expanding it there is nothing inside). I suppose that on windows this folder will correspond to drive letter, but I’m not sure here.  Now I only need to tell Team Framework that there are some files inside home node …

This seams to be quite easy task, since parent folder is already included in view … but this isn’t that easy. First of all Workspace model is based on IResource‘s with are manageable by Eclipse platform. Of course I can create such resource using IWorkspaceRoot.getFolder() and IWorkspaceRoot.getFile(). Unfortunately non-workspace resources created by those two methods will return theirs first segment (on unix system it will be usually /home) as theirs project. Of course such project doesn’t exist in workspace therefore this node is empty.

Honestly speaking I currently don’t have any good ides how to move things forward … as usually I’ll dive into debugging and code analysis …

Any hints and ideas from the community are kindly welcome!

For last few days I was working on EGit Synchronize View performance, especially on Workspace presentation model (the Git Change Set is next on my list ). My starting point was 1m 40s to compare two linux kernel versions, v2.6.36 versus v2.6.38-rc2. Such result seams to be very good, but you need to know that it was achived on SSD hard drive and comparing to regular HDD it would be much worst (maybe more then 3 or 4 minutes).

What can be improved ? Fist of all, current implementation whenever it is asked for members of particular folder it opens repository* and read data directly from it. Of course there is a cashing mechanism, but it is only on single resource level. Therefore when you are launching synchronization on repository that have about 300 folders, current implementation will create and configure 300 connections* to repository to read data and then will cache it.

So, my idea was to create only one connection*, read all data at once and put them into global cache. This cache will be used whenever any list of members for given folder will be required. This approach gives about 2.5x performance boost to synchronization (from 1m 40s down to 40s). This result looks much better and maybe on HDD this action will take less then 2 minutes … but this isn’t over

Reading members of folder is one thing, but getting information about particular file (it is changed, added or removed and does this change is incoming, outgoing or conflicting) is another. Currently we are reusing default implementation of SyncInfo class from Team Framework. This is really good implementation … when you cannot obtain such information from version control system. In Git  we have SHA-1 for each file and folder version and we didn’t have to compare file contents to check they are similar or not, comparing SHA-1 is sufficient. This should save lots of CPU time, disk IO’s and developer time waiting for synchronization to finish .

Now when I already have cache that contains list of all changed resources it was natural thing to add information about change type to it. Then whenever Team Framework need to know change type it can be easily obtained from this cache … no IO’s are needed, no comparison just read from in-memory-cache and return proper value.

I’m sure that you are wondering how fast synchronization can be now … I can only that it is REALLY fast … as you can remember my stating point was 1m 40s, now same comparison will finish in less than 7s!! This means that now synchronization will be 14 times faster then before! What this means for a regular user? Well, it meas that you will get results of ‘Synchronize Workspace‘ action almost instantly.

Unfortunately, mentioned above changes are sill awaiting for review in gerrit, you can grab them from change #3891 and build it locally. I hope this will be included in 1.1 release …

* jgit uses concept of walks (with filters) through repository, but I’ve used more commonly recognized terminology here

The EGit 1.0 will be officially released in upcoming days, but I’ve already started to working on version 1.1. Today I would like to demonstrate you a feature that I was recently working on. To be honest the main idea of this functionality comes from my GSoC 2010 proposal, but I didn’t manage to implement it … until now , so what it is?

The post title should told you everything about it … but (if not) I’ve also prepared a screencast that is embedded above where you can clearly see how it works in real environment.

I know that in version 1.0 the Staging view was introduced, to be honest, I don’t think that separate view for staging is really needed. But I don’t have anything against it, it looks cool and works properly . Also I don’t see anything bad with having this functionality doubled in Git Change Set model and give users possibility to choose between both of them.

I’ve pushed this feature (and all dependent changes) yesterday. This is quite huge change so I think that we’ll iterate few times with it before it will be merged into master, but I hope it will be included in 1.1.

As always feel free to share any ideas and comments!

One part of my Google Summer of Code project is to improve EGit Synchronization workflow and make it easier for new user to understood how it works.

So almost two weeks ago I’ve write a post with proposed new workflow for Synchronize Wizard. The main idea of that post was to initialize discussion with community how they want to use this wizard. According to Google Analytics this post was displayed around 120 times with isn’t that bad I think … but only one person leave a comment on it with isn’t a good result. Maybe I’m doing something wrong or I’m not making myself clear enough. Or maybe this topic isn’t so important for other people … I don’t know, maybe you can help me and give me some hints?

Apart from this, here is another part of changes that are proposed to be done in Synchronize workflow. Most of them are waiting for comments and approval in gerrit. This a good moment for comments and share thoughts about current implementation, before it will be merged into master branch. Additionally I’ve opened two bugs for discussion on Synchronize Wizard and Team menu based workflows:

• 344891 – for Team context menu
• 344888 – for sync-wizard

I’m understood that you don’t want to play with our code base and struggle with project setup only to check one of two new features, so here is a short description of my ideas and some screenshots:

1. Always use current selected branch (HEAD) as source of synchronization
   As you may know currently the synchronization-dialog (this is a dialog that pops up after you select Team > Synchronize… from project’s context menu) allows select source and destination branch, and after that you can launch the synchronization action.When I was implementing this feature I had in mind git diff command, where you can easily compare two given points in repository history. But this command produces a patch-like output. You cannot move changes around, the only action that you can do with it is to only review it. In case of Synchronize View we use to use it to move changes around and prepare commit. So it is more then simple git diff.

   Another huge issue with this approach is that handling Synchronize View context menu actions like ‘Commit‘, ‘Merge‘, ‘Overwrite and Update‘ gets really complicated when base branch isn’t actual working branch.

   Because of that I’ve decided that in new workflow you need to select only a destination branch! For now I think that I’ll not remove this functionality from EGit code, because maybe in feature we’ll found a use case when comparing two given branches without switching on one of them could be use full.

2. Always fetch changes before synchronization
   I’ve spotted that new git users that comes from CVS or SVN doesn’t really get the idea of ‘fetching changes locally’. They launch synchronization and want to see incoming changes without fetching them into repository. This feature could be also useful for old git users, because it will save couple of mouse clicks The implementation that I’ve proposed don’t launch fetch action all the time. It checks does current branch tracks any remote branch, if yes it fetches changes from that remote, otherwise it will not do anything.

   OK, but what when I’m off-line and I’m working on branch that tracks origin/master, I would be forced to wait until connection timeout occurs?

   Well … it depends Every time fetch fails you will be informed by dialog that you can disable automatic-fetch in Team > Git preferences. So in the worst case you will wait only once for connection timeout, then you will be informed that you can disable auto-fetch.

3. New Synchronize Wizard
   After discussion in bug 344888 I’ve decided to abandon changes that I’ve presented two weeks ago. And implement it this way:

   As you can see there is only destination branch. Also all project names have decorations that describes repository name and current branch name. There i a single button for include local changes and that’s all, no more pages and logic’s.

   Additionally, the Destination branch list will contain also additional refs like FETCH_HEAD

4. New context menu option ‘Synchronize Workspace’

   

   This a short cut for comparing HEAD against HEAD with included locally made changes. It is useful when you want to see what changes you made in workspace before you commit them. I think that this is a most use case for synchronize view therefore I’ve decided to add this shortcut.

5. No more Synchronize-dialog
   This a Matthias Sohn idea to replace synchronize-dialog with dynamically build sub menu entry (same as in ‘Switch To‘ action).

   

   This sub menu will contain 20 elements at most. They are alphabetically ordered and include local and remote branches, tags and additional refs like FETCH_HEAD. You don’t find here HEAD and name of current selected branch, because for synchronizing against those is ‘Synchronize Workspace‘ action. If you don’t see branch or tag that you would like to synchronize against, you need to choose ‘Custom…‘ option. After that the Synchronize Wizard will be shown where you can choose destination from complete list of branches, tags and additional refs.

6. Push and Pull actions in Synchronize View toolbar
    

   

   This change is merged into current master, so if you want to check out that you need to install a nightly build of EGit.

   There is only one limitation for push action, it works only when you are synchronizing one repository. It would be disabled when you synchronizing more then one repo.

It is all for now. Any ideas and comments are welcome (and needed )!.

Here are some screenshots of new redesigned steps in EGit synchronization wizard. The main idea is to make most common synchronization usage as short as it is possible. So I come with idea of ‘predefined synchronization configurations’. In first step of sync-wizard you can select from three options:

• Working Tree
• Remote Tracking
• Custom

After selecting first option you only uncommitted local changes (those that are stager/in index and those that aren’t). This should help you when you want to review yours changes just before commit or stage some changes.

Second option ‘Remote Tracking’ is only available when current branch tracks one of yours remote branches (if it doesn’t this option is disabled). This option will show you all locally made changes (same as in ‘Working Tree’) but also changes made in commits that occurs in local and remote branch after you started the local one.

Selecting one of those two actions (and selecting the checkbox next to repository name) will enable the ‘Finish’ button and you are done with launching synchronization.

In case when at least in one repository the ‘Custom’ option is selected, the ‘Finish’ button will be disabled, but ‘Next >’ should be enabled. In this situation you must go to the next page to setup yours custom synchronization.

On ‘custom synchronization step’ you will only see repositories that was chosen to have a custom synchronization. Here you can select source and destination branch and also include or exclude local changes from being shown in synchronization results.

Those changes are currently pending for a review in ours gerrit, but I think that they will be merged into master branch (not they won’t be included in 0.12 release).

What do you think about such approach for git synchronization? Maybe you see some other ‘predefined’ day-to-day synchronization configuration, if yes please let me know!

Almost 24 hours ago Google announces list of accepted projects in this year edition of Google Summer of Code program. In current edition Eclipse Foundation got 17 slots (as you may know from Wayne post). One of this slots was allocated for me (as a student) and Matthias Sohn, the project that we’ll be working is a continuation of my last year work for EGit project. The project name is “EGit Synchronize View support part 2″, if somebody is curious what this project is about you can check it on melange’s (I’ve made it public). In this proposal I want to address most important missing features in current implementation of EGit Synchronization support. If you think that something there is missing pleas let me know via mail or comments!

Apart from that I’m third time GSoC student (and that Eclipse got 17 slots!) there is another good news for me … on the list of accepted proposals in Eclipse Foundation there is 6 (six!) student’s names that looks like there are from Poland! Yeah! 1/3 of Eclipse GSoC students seams to be from Poland, this is really great information! Next great thing is that four projects are mentored by Polish mentors! Great work guys! And good luck

And last but not least, as far as I know there is one other student from my university that was accepted in GSoC11. This is some kind of regression comparing to 2010 edition where there were three accepted students. Maybe in next edition this will be improved, we’ll see.

After announcement the “community bonding” time begins … but not for me since I’m quite well integrated with EGit community therefore for me the “coding period” starts today ;>

Synchronize view in EGit doesn’t show non-workspace files from its very beginning. This issue seams to be very complicated and also it seams to require lots of hacking on team framework and eclipse API.

Few days ago Ilya Ivanov from Intland pushed into our gerrit a patch that should fix this issue. I was very surprised that this change is so small and simple. It only works partially because the compare editor cannot be launched for non-workspace files. In my opinion this patch cannot be merge into master branch without this core functionality, so today I spent about 3 or 4 hours hacking on that topic … and here are results:

As you can see, there is master pom file (with isn’t imported into eclipse workspace) in synchronize view and on the left hand side there is a compare  editor for it, showing what was changed ;>

Currently both patches are waiting for review in gerrit, but I think that they will be merged into master soon

Last week I spent in Walldorf (Germany) at EGit hackfest. I want to attend on all sessions therefore I’ve decided to go there day before and leave Walldorf day after event. Therefore I had some time that I can spent on short tours in Walldorf and Frankfurt. Here is a short summarization things that we manage to achieve during this time in case of synchronize view in EGit.

With Christian Halstrick we manage to speed up synchronization operation. Our starting point was comparing branch stable-0.7 against stable-0.10 from EGit repository with at the beginning takes around 2 minutes. Then using yourkit profiler we manage to reduce synchronization time down to less then 20 seconds on the same data set! The first set of patches that gives most acceleration were already merged into master and are available in latest nightly build of EGit, but there are also some open change sets in gerrit pending for review that should give some performance boost. Even with this improvements synchronization on some large repositories can take more then 5 minures, therefore this topic is still open for me and I’ll continue to hacking on it in feature. Currently one of the slowest part is mapping path of file/folder from git into eclipse’s workspace resource, but this should be improved by new implementation of IWorkspaceRoot.getFileForLocation()/IWorkspaceRoot.getContainerForLocation() in Eclipse 3.7 ;>

Second task that I manage to start working on during hack sessions is supporting context menu action in synchronization. I didn’t finish it but most of code is currently written. I only need to improve some things and test it. I think that in week or two this change should appear in gerrit.

This was great opportunity for meet persons that I only know from mailing list or code reviews in gerrit, especially to meet Matthias Sohn and Stefan Lay and also rest of EGit team members ;>

I want to thanks Matthias Sohn for organizing such great event and SAP for hosting it!. Many thanks also for my employer NCDC for refunding me part of my trip.

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.