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:
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:
- 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.
- 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.
- 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
- 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.
- 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.
- 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 ;))!.
I’ve been evaluating DVCS for my company’s use, and the biggest challenge I’m facing right now is communicating local vs. remote repositories to them. Heck, I even fall into the trap of “hunh I committed this, why didn’t my change get picked up by Jenkins?” It’s very easy to commit locally, and forget about impacting others in a sane way.
My experiences lend me to two ideas you might be able to use:
1) Make the eGit synchronize view display local changes, as well as for a push/pull to a remote. I would absolutely explicitly break them out into “these changesets come from upstream”, and “these changesets can be applied to your local repository”. Committing to the local one should cause it to become an outgoing change to the remote, for example. That will help educate and re-enforce to users how the DVCS model works.
2) Eliminate most of the git options from the project context menu – it’s too easy for novices to work on a single-file level, when they should really be considering all the changes they’re working on, or could consistently pull in. If the single file operations pushed them harder towards the Team Synchronize view as a whole, they might be better suited towards organizing their changes, and ensuring they keep their own working state functional.
Maybe only #1 is something you could consider in your GSOC role, but it would be a help in my opinion. Of course, my opinion doesn’t matter much since I’m not an Eclipse committer (maybe someday!).
@Jim
In my humble opinion you cannot move a team from VCS int DVCS with out any effort. When somebody starts with git he need to learn some git-specific terminology like:
* push
* fetch
* pull
* stage/index
and so on and so fort. In case of yours “push problem”, the key point, from my perspective, is to show that every one has his own repository and he need to “manage” it.
#1 We already had some discussions about default presentation model in sync-view. For some time the default model was ‘Git Change Set’ model, now we use ‘Workspace’ model. ‘Git Change Set’ model already splits up local changes into ‘working tree’ and ‘staged changes’. IMHO it is reasonable to split up commits into local and remote as you suggested, maybe I’ll even work on this in nearest feature.
#2 I’m not a fan of simplifying EGit. You need to remember that apart form new users there is also a huge group of advanced users and I don’t want put any limits on them. I would rather say that newcomers need to get some initial knowledge then that EGit should hide some of git features.
Yours opinion really matters! It matters even more than opinion of committer’s because they/we don’t think like normal users. They/we have distorted opinions because committers are creating features. For me the best example of such situation in sync-dialog with is perfectly clear for me and I know how powerful it is, but it is completely unintelligible for new users! As I write at the end of my post, any thoughts and comments are really welcome, especially now when we are close to 1.0 release.
Maybe I’m not using git ‘the right way’, but I’m a little surprised there is a toolbar item for push, but not commit. I usually use the sync view and commit locally and then (at some later point) I push my changes out.
Pingback: Pedro Newsletter 16.05.2011 « Pragmatic Programmer Issues – pietrowski.info
@Ian Bull
Those buttons are for people that immediately after commit push theirs changes or fetch changes from remote during synchronization. It seams reasonable to have those buttons in toolbar, otherwise you need to switch to Package Explorer or Git Repositories to be able to push/pull changes.
Maybe we should also add commit button into sync-view toolbar. But I’m not sure about this idea since commit action is in context menu.
Right,
I guess I’m just used to the commit (and merge) buttons from the CVS synch view. I use the context menu, so it’s not really a big deal.
BTW, great work on the synchronize view. I find this the most important view when working with any SCM, and your git implementation is getting better with each release.
*Push and Pull actions in Synchronize View toolbar*
I think this is a very bad idea. All the other buttons in the toolbar just change the view of the data in the synchronize view. IMHO actions which change the state of the system (e.g. push, pull) should live off the context menu (and this is consistent with all the other team providers: CVS, SVN, ClearCase, etc.).
As it stands users will inadvertently make changes to their local repo. or the master repo. without knowing it!
@Dariusz I’m trying to re-create a deleted resource via the synchronize view. The file shows up as difference but if I select the file in the synchronize view and select Replace with -> “File in Git Index” nothing happens.
What is the right process to restore a deleted resources which is not yet committed?
@Ian Bull
I’m using CVS for almost four years and never used those buttons, to be honest I didn’t ever know that there are buttons like ‘Update All’ and ‘Commit All’
@James Blackburn
Actually there is a “race condition” here, because when you commit all files you will end up with empty synchronize view and can’t access context menu, because you don’t have element on with you can click! Therefore after committing all changes you should use the toolbar ‘Push’ button.
@Lars Vogel
There should be ‘Overwrite and Update’ action in sync-view context menu … but currently it isn’t there; it is also part of my GSoC to add it. Currently you need to switch into eg. Package Explorer and then do Replace with … > File in Git Index
@Darlusz
I guess it’s my workflow then. I usually sync my entire workspace and look through each change. If I don’t want the change included (maybe it was a setting file or something), I ‘exclude from view’. In some cases I edit in my sync view (fix docs, typos, etc…) Once I’m happy with my commit tree, I hit the commit all, and use a single commit message for everything.
Hi Dariusz,
I would love to see the Synchronize View just focus on the workflow of pulling and committing/pushing and make that as comfortable as with the CVS Synchronize View. It should be easily possible to see what changes are incoming and outgoing, which is something EGit sorely lacks at the moment (looking at the branch labels in the History View isn’t usable).
For comparing arbitrary branches, that can already be done from the History view by selecting two commits -> Compare with each other in tree. And comparing the working dir can be done using Compare with -> Branch, tag or reference.
I don’t see why the Synchronize View even has to have the “compare two arbitrary tags/branches” feature, it just adds unnecessary complexity where it isn’t needed. Removing it would enable the Synchronize View to always have HEAD and (optionally) the working dir changes as the “source” part of synchronization.
@Lars Vogel
This is currently not supported by EGit, see the following bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=345002
and this one:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=333049
Hi Dariusz,
it’s great to see someone care as much of the Synchronize View as you do. I hope most of your changes make it into some official version of EGit.
Did you ever try out the Synchronize View from HGEclipse?
While I didn’t feel comfortable with the Synchronize View from EGit in the first place, HGEclipse really was a step forward.
Not only does it remove commited changes, but it also shows open pushs and pulls helping to remember new users that a commit alone is not enough (and also giving pros the chance to push/pull immediatly after commiting)
This idea was brought to your attention some comments above and I just wanted to tell, that I like this idea pretty much as well.
Cheers
Stefan
@Robin
I think that you have right, I’ve missed somehow idea of pure synchronize and mixed it up with ‘compare with’. But to be honest, I’m not sure does it is a bad approach. Git is very powerful and flexible tool. I see some use cases for synchronizing two branches and cherry-picking some commits. Such operation IMHO should be possible in sync-view instead of compare with.
@Stefan Hansel
I didn’t play much HGEclise, I used it once for couple of minutes and see some screenshots of synchronize view.
I’m afraid that we cannot simulate same behavior in ‘Workspace’ model with we decided to be a default one. But this should be easy to achieve in ‘Git Change Set’ model. But before that I need to figure out why synchronize view doesn’t refresh after commit.
Hi Dariusz,
First, thank you very much for your great work with the Synchronize View. It’s finally become really useful in my day-to-day work 😀
One thought about the “Synchronize Workspace” action though: In the traditional CVCS workflows, the standard workflow is to synchronize incoming and outgoing changes in one go. I would have expected something similar available as a standard workflow with EGit, too, i.e. synchronizing incoming changes from default upstream (merge) and outgoing changes from the workspace (commit) into HEAD.
I know that I can get that by selecting the correct upstream branch from the dynamic “Synchronize” sub-menu. But having a no-brainer standard action like “Synchronize Workspace” that I can easily assign a shortcut to would be so much more awesome…
@Carsten Reckord
Actually in 1.0 you should be able to see incoming changes if yours local branch tracks remote one. In such case EGit will fetch changes from remote repository and should display them as incoming.
Another thing is that current synchronize view implementation doesn’t support merge or rebase action therefore if you see incoming changes you should use ‘Team’ context menu or toolbar buttons to merge or rebase.