Since of May 16 I’m officially working on integration EGit with Synchronization View. Right now I know that this task is more complicated then I was thinking before GSoC. But thanks Remy Suen and his initial contribution to EGit which gave me some foundation this isn’t so scary as it could be ;). Here is a very quick overview of current situation.
Currently there are three way to launch synchronization:
- From synchronize wizard
Second step of wizard requires some work, it has some usability issues … - From branch context menu in Repositories View
In this case we are synchronizing current HEAD (active branch), with selected branch; locally made uncommited changes are excluded in this comparison. - From project’s context menu by selecting Team -> Synchronize
After this we would see above dialog:
Where we can select source and target branch or tag (both are supported) and declare does we want include local changes in this comparison
No matter with way will you use, you always will see something similar to this:
When you will use EGit Synchronization view there are few important things that you have in mind:
- Synchronization always occur on repository level. What it means ? It means that you cannot synchronize a single folder or file (for “file synchronization” there is a Compare With -> HEAD Revision / Git index). If you have more then one project in repository (eg. two or more maven modules), synchronize action will compare all of them.
- Changes are organized in commits and can’t be extracted or moved between them. You can only merge entire commit.
This two things distinguish Git from CVS/SVN.
This isn’t end of my work with synchronization view. There are lots of things that should be improved, implemented and fixed 😉 eg.:
- showing proper files in Compare view (currently compare view always compares local file with remote, in some cases it should compare file that is in selected branch instead of current local)
- splitting changes into commits when we will presenting it in Synchronize view (this is important because after it would be implemented we can start thinking of implementing merging from synchronize view)
- performance improvements
- usability improvements
- (and of course) bug fixes 😉
This looks already very good. Should it also not possible to compare between individual commits? Say I have commit with SHA1 and want to compare it with SHA2_
@Lars Vogel
Yes, in deed CGit supports comparing two commits, and even more, you can checkout a commit. But right AFAIK now JGit doesn’t support checkouts on commit level.
Comparing two commits should be easier then checkout. To be honest I didn’t think about it before … but right now IMHO the only reasonable way to do it, would by adding and additional menu option (beside of ‘Synchronize …’) eg. ‘Compare commits’ (this can be added into ‘Compare With’ menu instead (all ready huge) ‘Team menu’) or ‘Synchronize commits’. I’ll prefer to distinguish this feature from ‘Synchronize dialog’ because this dialog is already complicated enough.
I’ll add it to my TODO list, thanks for pointing that out 😉
Great work Dariusz! It’s good to see progress especially that we started the IP review process on the initial contribution!
Interesting work. I like seeing git become more ‘mainstream’ into eclipse tooling. I’ve used git for almost two years. It fun to watch the experts bring it into eclipse.
I’m unsure of what ‘synchronization’ means in a distributed vcs. It must mean something different than in the centralized vcs, won’t it? I’m sensing a fuzzy. In the git command line, I don’t see a ‘synchronize’ operation. In other words, what git commands would I run from the command line if I want to do the same thing as eclipse ‘synchronize’?
Thanks,
John
Do you have a p2 repo with the code for us to test drive it?
@John Franey
Yes, synchronize in case of git is quite fuzzy as you said. I would say that in current status ‘synchronize’ should be equivalent to ‘git diff’ (you can compare two branches, two tags or tag against branch and vice versa). But IMHO in feature ‘synchronize’ should be much powerful then ‘git synchronize’ because it should split particular change into commits and show list commits, then you would be able to merge this commit into current branch (this only a simple use case since there could be more then one commit in view…)
Generally (for now) I would prefer to have quite similar synchronization-workflow as we have now in CVS plugin.
@lemmy
No, I don’t have a public p2 repo and I don’t plan to have one. You can wait until this change will be merged into current build and download it from EGit’s nightly build repository. Or build on your own using patch set from gerrit and build sequence described in EGit contributor guide
Pingback: Dariusz [LocK] Łuksza » EGit preliminary synchronization view support merged!