Posts Tagged → change set

Show non-workspace resources in Git Change Set

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 😉

EGit ChangeSet shows staged and working tree changes

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.

Staged and working tree changes in Synchronize view
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.

EGit Synchornize ChnageSet – implemented!

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! 😉

EGit Synchornize ChnageSet – discussion

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 ;>

EGit Synchronize ChangeSet – a small step ahead

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):

<img class="aligncenter size-medium wp-image-629" title="egit-synchronize-change-set" src="https://luksza More Info.org/wp-content/plugins/speed-booster-pack/inc/images/1×1.trans.gif” data-lazy-src=”https://luksza.org/wp-content/uploads/2010/07/egit-synchronize-change-set-223×300.jpg” alt=”” width=”223″ height=”300″ srcset=”https://luksza.org/wp-content/uploads/2010/07/egit-synchronize-change-set-223×300.jpg 223w, https://luksza.org/wp-content/uploads/2010/07/egit-synchronize-change-set.jpg 382w” sizes=”(max-width: 223px) 100vw, 223px” />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.