Community
Participate
Working Groups
Eclipse EGit (Incubation) 0.10.0.201010041519 org.eclipse.egit.feature.group I've marked this as major as I believe the current UI is inadequate for using egit for single user work. There seems to be no easy way to compare the current working tree with HEAD of the current branch. I haven't yet figured out how to easily use egit for committing changes and end up dropping back to the command line. - Compare with > ... is disabled at the project level (bug 315555) - Team > Synchonize brings up a confusing dialog: - Source Repository Ref <local.git> HEAD - Desintation Repository origin master Ticking "Include local uncommitted changes in comparison" disables the source group. - Synchronize takes a long time when just comparing current (un)staged changes to HEAD (Bug 323839) Problems: + What do source / destination mean? Without performing the synchronize I can't tell (the major clue is given by selecting "Include local uncommitted changes...). + For Destination origin/master appears to be an arbitrary choice. I'm sat on branch bug/309769_project_references and my .git/config has: [branch "bug/309769_project_references"] remote = brcm merge = refs/heads/bug/309769_project_references If I'm trying to stage changes for commit I really want to be synchronizing against HEAD of my current branch (and really the branch name should be mentioned explicitly rather than <local.git>/HEAD which requires knowledge that HEAD is the tip of the current branch in the repository). It seems that most the UI components are in place, it's just that the workflow is rough around the edges.
I had marked it major as I couldn't find a work flow that allowed me to use egit for committing within the IDE. I kept needing to drop back to the command line. AFAICS this is a major impediment to rolling out egit to users, as without a straightforward compare and commit you'll have lost many users at the first hurdle. From my POV usability here is way more important than feature completeness on lesser used features. Looking at the latest nightly build (0.10.0.201010190321) the work flow hasn't changed.
Currently the recommended way to see the changes compared to HEAD is to open the commit dialog. There you see the list of changes that would be committed. There are discussions about a staging view (Bug 313263). There is a bug about comparing folders or projects (Bug 315585). I agree that these features, together with the tuning of the synchronize view, would be very important. But for my daily work the list in the commit dialog is sufficient. I never commit from the command line. Because of that we considered this as an enhancement request rather than a bug.
The commit dialog does not give any clue that you could open compare mode with a double-click. And even if you do so, it is not possible to do minor editing as it is read only unlike in CVS plugin. It is a real pain. I am still using it because I am unable to use Synchronize view due to its great slowness. I waited for half an hour once and it had not finished. My project is fairly big.
Code review at http://egit.eclipse.org/r/#change,2497
merged as 2e6a9708f29307b1a62a3a0d0c689ae02fcdd7b0 So we now have "Compare with HEAD" and also improved synchronize performance considerably. Could you give it another try using the nightly as soon as it contains this change and let us know if you are happy here ?
(In reply to comment #5) > So we now have "Compare with HEAD" and also improved synchronize performance > considerably. Could you give it another try using the nightly as soon as it > contains this change and let us know if you are happy here ? I've just had a play with the current nightly and the workflow (to me) still seems confusing. egit provides both a Synchronize hook and now its own custom Git Tree Compare View. The new "Git Tree Compare View" is like a poor-man's synchronize view (i.e. a jface tree with no actions or functionality...) - It's hard to iterate through the changes + Working with this on a deep project (e.g. a Java Plugin Project) is almost impossible - There are no actions (e.g.) to add, overwrite, delete - There's no way to open a file in an editor. Compare this with the synchronize View in Workspace model. This makes it easy to see all your changed files, edit them, etc. Moreover you can continue editing in the workspace, and the changes auto-magically appear in the synchronize view! I'm just confused as to why there are two ways to do the same thing? Coming from CVS, the Synchronize view was basically a staging area, and no doubt there needs to be some thought on how this should interact with the index... When I compare my working tree with HEAD (or Index with HEAD), I'm getting ready to commit, and I'd really like to be able to see what will happen when I do press commit. I'd also like to be able to do this without entering the modal commit dialog. If you could take the existing synchronize view, make it the target of compare with, and make it show the workspace model by default (the "Git Change Set" model is not useful, imho), then I think egit would be most the way there. It might also be useful to toggle: WS vs. HEAD, Staged vs. HEAD, and WS vs. Staged. However it's very likely that IDE users with almost always just be interested in 'WS vs. HEAD'. When they select files for commit, I'd bet they're almost always doing a commit -a on the selected files. In all this I'm just trying to find a workflow that allows me to stage and review my staged changes before entering the commit dialog. Does that make sense?
Then you should give http://egit.eclipse.org/r/#change,3355 and its predecessors a try. Based on prior work from Remy Bernard is on the way to implement a dedicated staging view featuring a UI similar to GitX which is meant to solve this problem in an efficient and convenient way.
Is this still a problem, now that the Staging View has been available for some time?
(In reply to comment #8) > Is this still a problem, now that the Staging View has been available for some > time? Right, I've switched to using Staging View even if it is still darn slow, order of magnitude slower than command line git. Big progress in comparison with what was before though.
I think this is solved by the Staging View which is around since a couple of releases. Also performance of the staging view has been continuously been improved. In order to catch up with performance compared to cgit we need faster access to file system meta data which becomes available with Java 7 (we also started implementing a tiny JNI library a while back [1] but this effort is stuck due to the much more complex build and release process inherent to native builds). Leveraging NIO2 is tracked in bug 353771. [1] https://git.eclipse.org/r/#/c/1815/ https://git.eclipse.org/r/#/c/2126/
