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 😉