Community
Participate
Working Groups
EGit 1.1 Make sure there are multiple files with several changes in each file. - Team -> Synchronize - In the Synchronize View toolbar, click on the "Next Difference" tool multiple times to cycle through the changes. (Alternatively, type ctrl+.) When looking at CVS changes, this will select every change in every file. With Git changes, this only selects the first change in each file, and then the user has to move over to the editor's "Next Difference" arrows to see the rest of the changes. (Imagine how complicated this would be with keyboard only). The CVS method was more efficient because the user doesn't have to move the mouse. (or they can just keep typing "ctrl+." to see all changes). The CVS method was also less error-prone, because you are guaranteed to notice that debug code you accidentally left in a file, because you will see every single change, and not just the first change in each file.
*** Bug 362377 has been marked as a duplicate of this bug. ***
This is still not fixed in 1.2, and is really slowing me down. I'd be happy to help in any way I can, but I don't have a clue how to develop Eclipse plugins right now.
Forgot to mention this... Changing the preference for what to do when the end of the file is reached (in General | Compare/Patch > Text Compare) is having no impact here. If I change it to "Prompt", I do see the prompt to go to the next element, but that doesn't actually happen.
This is a really annoying bug. Any chance that this gets fixed soon?
*** Bug 465511 has been marked as a duplicate of this bug. ***
I would also be very interested in solving this problem. I tracked the problem down to the following issues: EGit UI Plugin: Class GitModelSynchronizeParticipant, Lines 187-192 Object oldNavigator = configuration.getProperty(P_NAVIGATOR); if (!(oldNavigator instanceof GitTreeCompareNavigator)) configuration.setProperty(P_NAVIGATOR, new GitTreeCompareNavigator((CompareNavigator) oldNavigator)); -> here the usual TreeCompareNavigator is intercepted using a wrapped GitTreeCompareNavigator Class GitTreeCompareNavigator, Lines 39-43 baseNavigables = COMPARE_NAVIGATOR_CLASS.getDeclaredMethod("getNavigatables", Void.class); baseNavigables.setAccessible(true); return (INavigatable[]) baseNavigables.invoke(mainNavigator,Void.class); -> This code contains a bug and seems never to have worked as supposed -> This code always throws an NoSuchMethodException which is catched silently -> Code should be like this to work: Class GitTreeCompareNavigator, Lines 39-43 baseNavigables = COMPARE_NAVIGATOR_CLASS.getDeclaredMethod("getNavigatables"); baseNavigables.setAccessible(true); return (INavigatable[]) baseNavigables.invoke(mainNavigator); -> Remove both ", Void.class", since reflective call is without any parameters. Back to the key binding problem: - With the code above, the getNavigatables Method does not return any navigatables. Therefore the Compare UI always switches to the next File instead of selecting the next difference in the open file. - Unfortunately fixing the EGit-UI code like described above does not solve the problem. The fixed code leads to a StackOverflowError: GitTreeCompareNavigator.selectChange(boolean) line: 69 AbstractTreeViewerAdvisor$TreeCompareNavigator.selectChange(boolean) line: 58 GitTreeCompareNavigator.selectChange(boolean) line: 69 AbstractTreeViewerAdvisor$TreeCompareNavigator.selectChange(boolean) line: 58 GitTreeCompareNavigator.selectChange(boolean) line: 69 NavigationAction.run() line: 64 The cause of the problem is the following The GitTreeCompareNavigator wraps an instance of the private class TreeCompareNavigator and not a CompareNavigator instance. The TreeCompareNavigator uses a getSubNavigator() to navigate through the tree. The GitTreeCompareNavigator intercepts the selectChange() method and always redirects to the root top node, which tries to delegate to its childs and so on. Unfortunately after a long debugging session, I could not find a working solution for this problem. In my opinion the wrapping and replacement of the CompareNavigator instance in GitModelSynchronizeParticipant is a 'hack' which probably solves another bug, but disables the proper navigation through compare editor participants. Therefore this problem would be solved, if the CompareNavigator instance replacement could be omitted. As a workaround, I compiled a EGit UI plugin with commented lines 187-192 in class GitModelSynchronizeParticipantm which works for me.
if you want to contribute a patch fixing this problem follow the contributor guide [1] and push the fix to Gerrit for code review [1] https://wiki.eclipse.org/EGit/Contributor_Guide
This bug and https://bugs.eclipse.org/bugs/show_bug.cgi?id=395250 are somehow similar. (Cant't say whether they are actually duplicates.)
(In reply to Detlef Keil from comment #8) > This bug and https://bugs.eclipse.org/bugs/show_bug.cgi?id=395250 are > somehow similar. (Cant't say whether they are actually duplicates.) I think waiting for ADD_TO_INDEX/REMOVE_FROM_INDEX is really necessary. The hack was introduced in a change that enabled drag'n'drop between the <working tree> and <staged changes> children under <Git Commits> in the Team synchronize view when the git model provider is enabled. If those jobs take long (which they may if one selects a large number of files to drag), it's possible that the user clicks "next/prev change" before the jobs are done, and one may end up on the wrong node being opened in the compare editor since the node hierarchy should change in response to the actions performed by these jobs. Otherwise I agree with Paolo's analysis. It _is_ a hack; and it prevents switching to the next/previous node. There's also something strange about those Git model nodes; if a file under <Git Commits> is clicked and opens in the compare editor, switching to the next/prev node doesn't work at all; not even with Paolo's work-around. That one works only for the resource model.
*** Bug 502143 has been marked as a duplicate of this bug. ***
Still applies to 2020-09 (and I guess to newer releases as well). This is really annoying :-( Is nobody using the Synchronize view? I find it precious and the broken difference navigation buttons are impacting productivity a lot. The original report highlighted how those arrows behave with CVS, but with both Subversive and Subclipse they also work in the same way, i.e. they make you jump to the next/previous difference, not to the next/previous file. It's much harder to review changes in this way.
Making it even worse, when you use the "next difference" button on the compare view (instead of the one on the Synchronize view), if you reach the button of the file and then choose to "Display the next element", it won't work: nothing happens and you won't be brought to the next file. So there's no escape :-( I see now this was already mentioned before, but I wanted to stress the fact that there are at least two bugs here.
(In reply to Mauro Molinari from comment #11) > Is nobody using the Synchronize view? Well, I still use it... But the main charm of that view, was that you could go through all of the changes by just using keyboard commands (CTRL-. and CTRL-,). This was true for the "good" old days of cvs and svn, but it's not possible for git due to this bug. (Needles to say, that it still works for the cvs/svn team plugins, but most of the projects are on newer versioning systems now.) Stepping through the changes with a mixture of mouse clicks and key strokes is as well possible with the git commit dialogue or the git staging view. So many people are maybe not aware of the advantages of the synchronize view anymore. The consequence is that nobody cares anymore... It's a pity that this big seems to be sit out... at least ther's no fix for almost a decade :-(
(In reply to Detlef Keil from comment #13) > It's a pity that this big seems to be sit out... at least ther's no fix for > almost a decade :-( It's open-source, maintained by volunteers. If nobody is interested enough to contribute a fix there won't be a fix. I looked a few times, but as I don't use the synchronize view, it doesn't bug me. The few times I looked, I saw a number of other bugs in the synchronize view that might need fixing first. Also looks to me that the whole synchronize framework is intended to work with workspace resources only. Files in the git repository that are not part of any Eclipse project will give troubles. Since I don't use this view I have no incentive to dig further. But if it bugs other people hopefully someone contributes a fix. (Might not be easy, that waiting for jobs is there for a reason, even if it might be the wrong approach. Better would be to have models refreshed via an IndexDiffChangeListener, but that already doesn't seem to work properly currently, and would need to be fixed first. Then one could maybe forego this "replace the navigator" hack.) We welcome contributions. See https://wiki.eclipse.org/EGit/Contributor_Guide#Contributing_Patches for some guidance.
(In reply to Thomas Wolf from comment #14) > ... The few times I looked, I saw a number of other bugs in the > synchronize view that might need fixing first. Also looks to me that the > whole synchronize framework is intended to work with workspace resources > only. Files in the git repository that are not part of any Eclipse project > will give troubles. To me that is not very special to git: Every versioning system (even cvs!) has files, that are not existing in a locally checked out Eclipse project (or more generally software project). Either they are not yet existing locally, or they have been deleted by intention, or they are outside of the project's base directory. The synchronize perspective can cope with that fact at least for the team providers cvs and svn. What you said, could be the root cause of the whole thing: The Team plugin is designed to see only the Eclipse projects, but the git plugin wants to look outside, too. After all, there can be only one git synchronization in the synchronize perspective, while there can be lots of svn/cvs synchronizations in parallel. To me it looks like, there is some kind of misconception between the design principles of the Team plugin and the design principles of the Git Team provider.
I remember working on Synchronize view support in Mercurial Eclipse plugin few years ago, and adding support for that was a nightmare. The whole framework is extremely complicated and written around CVS (or Clearcase?) use model, it was not easy to adopt it to Mercurial. Also I had impression that the whole thing is over-designed and doesn't scale good. Since I use Git I never had a need to use Synchronize view as user, and my peers that never used CVS/SVN also never complained about Synchronize view because they simply don't use it / don't miss it in the daily work. (In reply to Thomas Wolf from comment #14) > It's open-source, maintained by volunteers. If nobody is interested enough > to contribute a fix there won't be a fix. I fully agree with Thomas. If someone needs Synchronize view that much, providing a patch is the best way to move forward here.
(In reply to Thomas Wolf from comment #14) > It's open-source, maintained by volunteers. If nobody is interested enough > to contribute a fix there won't be a fix. I always think this should not be used as an argument whenever one says there's something wrong. I have been using Eclipse since 17 years and I can say that the Synchronize View/Perspective is one of the most useful views in the whole IDE. I really wonder how git developers are overviewing their changes before commit, since I am not aware of any real alternative to the Synchronize View. The commit view by itself is quite uncomfortable and it's not really an alternative. Fortunately, my main activities are still on SVN, so I can still use this view profitably most of the times... but sooner or later one will have to deal with git. I'm quite convinced that people that don't have ever used the Synchronize Perspective don't know how useful it is just because they, indeed, have never used it. Sometimes I think that in the latest years the Eclipse IDE forgot why it has been so great to use in the past and perhaps this is the reason why other IDEs got more and more popular. > synchronize view that might need fixing first. Also looks to me that the > whole synchronize framework is intended to work with workspace resources > only. Files in the git repository that are not part of any Eclipse project > will give troubles. But AFAIK this is true for ANY resource within the Eclipse workspace, and it has always been so even when using SVN or CVS, so I don't understand the point. Any SCM action within Eclipse has always been workspace-centric and project-centric, so we may bring the whole model into question, but, given the current situation, I don't think the Synchronize View is weaker than any other SCM functionality within Eclipse for this reason. Unless you're telling me that you're not using Team functions and all and you're going by command line to perform any git activity...
(In reply to Andrey Loskutov from comment #16) > I remember working on Synchronize view support in Mercurial Eclipse plugin > few years ago, and adding support for that was a nightmare. The whole > framework is extremely complicated and written around CVS (or Clearcase?) > use model, it was not easy to adopt it to Mercurial. Also I had impression > that the whole thing is over-designed and doesn't scale good. > > Since I use Git I never had a need to use Synchronize view as user, and my > peers that never used CVS/SVN also never complained about Synchronize view > because they simply don't use it / don't miss it in the daily work. Ok, so let's say that the Synchronize View, as it is currently designed, does not fit well for git (although, from a user point of view, I can't understand why, since it works so well for Subversion as well... and the problem it should solve is exactly the same, that is giving the user the opportunity to browse its local changes to review before committing). So, what do you use instead to perform this task? The git commit view?
(In reply to Andrey Loskutov from comment #16) > I remember working on Synchronize view support in Mercurial Eclipse plugin > few years ago, and adding support for that was a nightmare. The whole When I wrote there is a misconception of design principles, I didn't want to blame either of the two sides. I also fully agree with both of you, Andrey Loskutov and Thomas Wolf. Eclipse is open-source and I'm very happy with what we have in eclipse. Thus, I'm certainly moaning at a very high level... I know that. Sorry, if what I wrote annoyed anybody. For me it would be just "nice to have" a way to go through all changes using the keyboard as well with git. Whether that's in the synchronization perspective or anywhere else, I don't care. But for a "nice to have" feature my preasure is not so high, that I'll do a deep dive into the Eclipse internal team provider programming - including possible nightmares in the synchronization view ;-) On the other hand, what Mauro wrote in comment #17 has as well a point: The risk is, that people turn to other programms. May it be git GUI clients or even other IDEs. I for example found a git client, which helps me to get an improved view to what changed in my git repositories. I'd like to do all these things in Eclipse, but for some use cases that other git GUI client is just more convenient.
(In reply to Mauro Molinari from comment #17) > (In reply to Thomas Wolf from comment #14) > > It's open-source, maintained by volunteers. If nobody is interested enough > > to contribute a fix there won't be a fix. > > I always think this should not be used as an argument whenever one says > there's something wrong. It's not an argument; it's an explanation. It's just the way it is. Volunteers will do whatever they're interested in. If nobody is interested, nobody will fix it. Nobody is paid to fix bugs in EGit or JGit, and nobody is selling it as a product, and user's don't buy it and don't get a support contract, so they have no handle to make anyone do anything about it. Bugs and shortcomings in open-source products are only ever fixed if users affected provide contributions to fix them. Or sometimes because a regular contributor takes an interest and is kind enough to fix things even if they don't bother him or her personally.
(In reply to Mauro Molinari from comment #18) > opportunity to browse its local changes to review before committing). So, > what do you use instead to perform this task? The git commit view? That, or the compare view (comparing the commit I'm about to push with the upstream branch I want to push to; easily done from the history view). And I never have a need for the synchronize view to get upstream changes into my local repo; I just fetch or pull (and if there are conflicts, resolve them).
(In reply to Detlef Keil from comment #19) > On the other hand, what Mauro wrote in comment #17 has as well a point: The > risk is, that people turn to other programms. May it be git GUI clients or > even other IDEs. Sure. So what? As I'm not selling Eclipse or EGit and am not making a living out of it, why would it be important to me what other people use to work with? They can use whatever they feel most comfortable with. And if tomorrow there came a free (as in beer and speech) "Git-for-Eclipse" plugin that did everything much better, well, EGit would be dead. But the economics for that "free" successor would likely be the same. > I for example found a git client, which helps me to get an > improved view to what changed in my git repositories. I'd like to do all > these things in Eclipse, but for some use cases that other git GUI client is > just more convenient. Well, and that's perfectly fine :-) I'm sure these are visual git clients out there that can do certain things better than EGit. Heck, there are even Eclipse-based products that can do certain things better.
(In reply to Thomas Wolf from comment #21) > That, or the compare view (comparing the commit I'm about to push with the > upstream branch I want to push to; easily done from the history view). And I > never have a need for the synchronize view to get upstream changes into my > local repo; I just fetch or pull (and if there are conflicts, resolve them). You will agree with me that both your suggested alternatives are quite different from the Synchronize View from a user point of view. The git commit view is usually tiny, it extends horizontally rather than vertically and if you expand it so that it becomes less claustrophobic you'll most probably lose the editor (unless you have a giant 4K monitor or a multi-monitor setup, of course). In any case, you won't have a view with a hierarchical organization like the Synchronize View and if you work with a multi-project workspace it can make a difference. The Compare View is just one of the views of the Synchronize Perspective, but without the Synchronize View you just have a tiny view on what is going on, you lose the bigger picture. Having the ability of seeing what is going to be merged (the "incoming changes") is also a valuable feature for, me, especially when you also have some outgoing changes and you want to easily compare both. This is something you can't do easily without the Synchronize View in my opinion and pull+resolve conflicts might be too late in some cases. >Nobody is paid to fix bugs in EGit or JGit, and nobody is selling it as a product, and user's don't buy it and don't get a support contract, so they have no handle to make anyone do anything about it. >As I'm not selling Eclipse or EGit and am not making a living out of it, why would it be important to me what other people use to work with? They can use whatever they feel most comfortable with. And if tomorrow there came a free (as in beer and speech) "Git-for-Eclipse" plugin that did everything much better, well, EGit would be dead. But the economics for that "free" successor would likely be the same. Sorry Thomas, nothing personal (we're just discussing), while I perfectly know the principles behind "open source", I don't think this is the better way to lead a project. If Eclipse committers are the first one who don't care at all about their projects, I think there's something wrong. And, with this perspective in mind, the broader community (i.e.: whoever uses Eclipse and contributes in ways that are different from just coding) and its opinion become completely useless, if not even background noise. Perhaps I'm too much sentimental, but I think that some kind of respect for the users community is due... Otherwise let's close Bugzilla entirely or let it open only for committers.
We just have different workflows, and mine is such that I don't need the synchronize view or perspective at all. (In reply to Mauro Molinari from comment #23) > The git > commit view is usually tiny, it extends horizontally rather than vertically Oh, you mean the staging view. No, I didn't mean that. I meant opening a commit in the commit viewer. Sometimes a unified diff is all I need. (I also always first commit locally. I think I've never used the "Commit & Push" feature. I feel more comfortable with doing these in separate steps.) > multi-monitor setup, of course). In any case, you won't have a view with a > hierarchical organization like the Synchronize View and if you work with a > multi-project workspace it can make a difference. Of course I do. If I compare two commits (in history view: select two commits, then choose "Compare with Each Other" in the context menu), the commit editor opens in the large central editor area, and shows in the top part a hierarchical view. > Having the ability of seeing what is going to be merged (the "incoming > changes") is also a valuable feature for, me, especially when you also have > some outgoing changes and you want to easily compare both. This is something > you can't do easily without the Synchronize View in my opinion and > pull+resolve conflicts might be too late in some cases. In such cases, I fetch and then compare commits. For instance FETCH_HEAD against HEAD. As I said: it's just a different workflow. > I think that some kind of respect for the users > community is due... I don't know where this is coming from now. I do respect users, and I'm sorry I appear to have offended you. I do see that things with that synchronize view/perspective are not as one would expect. I was just trying to explain why nobody does anything about it: nobody who needs that view (I don't) is bugged enough by these problems to fix them. Don't expect the committers to do it all; there's not that many of them, even fewer are active (see [1]), and they all seem not to use that synchronize view. Other people can contribute, too! As I wrote above: we welcome contributions, and if someone can fix this integration with the Team synchronize framework and has the time to create some fixes and push them to Gerrit, that'd be good. [1] https://projects.eclipse.org/projects/technology.egit/who
(In reply to Thomas Wolf from comment #24) > Oh, you mean the staging view. No, I didn't mean that. I meant opening a > commit in the commit viewer. Sometimes a unified diff is all I need. (I also > always first commit locally. I think I've never used the "Commit & Push" > feature. I feel more comfortable with doing these in separate steps.) [...] > > In such cases, I fetch and then compare commits. For instance FETCH_HEAD > against HEAD. Just to conclude and to avoid any misunderstanding: do I have understood it right if I say that for whatever comparison in your workflow you must commit FIRST and then you "compare with each other" between two commits/revisions? If this is the case, then what I still feel it's a killer feature of an IDE like Eclipse is the ability to quickly/easily/graphically compare changes BEFORE commit. And the Synchronize View is precious exactly for this purpose. Yes, in git I can amend, but I strongly think that change->review->fix->commit is much more straightforward and quick rather than change->commit->verify->amend->fix->re-commit. Especially when your changeset is huge. And especially because in git (probably even more than in other SCMs) keeping commit history clean is very important.
(In reply to Mauro Molinari from comment #25) > (In reply to Thomas Wolf from comment #24) > > Oh, you mean the staging view. No, I didn't mean that. I meant opening a > > commit in the commit viewer. Sometimes a unified diff is all I need. (I also > > always first commit locally. I think I've never used the "Commit & Push" > > feature. I feel more comfortable with doing these in separate steps.) > [...] > > > > In such cases, I fetch and then compare commits. For instance FETCH_HEAD > > against HEAD. > > Just to conclude and to avoid any misunderstanding: do I have understood it > right if I say that for whatever comparison in your workflow you must commit > FIRST and then you "compare with each other" between two commits/revisions? I use a combination of quick diff and staging view to see what's modified before creating a commit while hacking on a patch. In addition I use git diff in a terminal using delta [1]. After committing I use compare and commit viewer starting from history view or the blame hover in the editor. In addition I use to upload changes to Gerrit, and review my own changes there before others working on the project review them. Maybe the commit viewer could be enhanced to provide a side-by-side diff similar to delta. I never really used the synchronize view and I am an EGit committer since 2009 :-) The underlying API is awkward and hard to map to the way git works. [1] https://github.com/dandavison/delta > If this is the case, then what I still feel it's a killer feature of an IDE > like Eclipse is the ability to quickly/easily/graphically compare changes > BEFORE commit. And the Synchronize View is precious exactly for this > purpose. Yes, in git I can amend, but I strongly think that > change->review->fix->commit is much more straightforward and quick rather > than change->commit->verify->amend->fix->re-commit. Especially when your > changeset is huge. And especially because in git (probably even more than in > other SCMs) keeping commit history clean is very important.
(In reply to Matthias Sohn from comment #26) > I use a combination of quick diff and staging view to see what's modified > before creating a commit while hacking on a patch. > > In addition I use git diff in a terminal using delta [1]. After committing I > use compare and commit viewer starting from history view or the blame hover > in the editor. In addition I use to upload changes to Gerrit, and review my > own changes there before others working on the project review them. Quick Diff is super-useful, but it's single file centric. The staging view has the limitations I outlined above. Command line, Gerrit and Delta are external tools, so they are not real Eclipse IDE alternatives. I had a look at Delta: it's interesting, especially if you don't have... an IDE! Leaving out Gerrit, which of course has also other features, the more you talk to me about alternatives the more I think that you're just missing that the Synchronize View can provide you with exactly the features you need from inside the IDE! It's all just a couple of clicks away and it would be even quicker if there weren't the bug outlined here :-( There were times in which Mylyn was doing some exceptional things with the Synchronize View, like the ability to automatically create and manage change sets when the concept of change set was missing (like in CVS) or limited (like in SVN). The "model" concept of the Synchronize View could probably be used to easily switch between comparisons against different bases (since in git we have the index, the HEAD, the FETCH_HEAD, remotes, etc. etc.); again, with just a couple of clicks. It's really a pity it wasn't given priority :-(
(In reply to Mauro Molinari from comment #27) > (In reply to Matthias Sohn from comment #26) > > I use a combination of quick diff and staging view to see what's modified > > before creating a commit while hacking on a patch. > > > > In addition I use git diff in a terminal using delta [1]. After committing I > > use compare and commit viewer starting from history view or the blame hover > > in the editor. In addition I use to upload changes to Gerrit, and review my > > own changes there before others working on the project review them. > > Quick Diff is super-useful, but it's single file centric. > The staging view has the limitations I outlined above. I'd rather improve staging view than fight with the synchronize APIs which were designed having CVS in mind. Maybe you can file a feature request explaining what you miss in staging view ? Did you notice that it flips to a vertical layout if its window height is larger than its width ? > Command line, Gerrit and Delta are external tools, so they are not real > Eclipse IDE alternatives. I had a look at Delta: it's interesting, > especially if you don't have... an IDE! I use Eclipse a lot but this doesn't prevent me from using additional useful tools. E.g. I use p4merge configured as git mergetool for complex conflict resolutions. Would also be nice to have a similar tool inside Eclipse but someone needs to spend the time to implement that. My days only have 24 hours, I am pretty busy maintaining basic stuff in jgit and keep pace reviewing changes Thomas writes faster than I can review and try them ;-) > Leaving out Gerrit, which of course has also other features, the more you > talk to me about alternatives the more I think that you're just missing that > the Synchronize View can provide you with exactly the features you need from > inside the IDE! It's all just a couple of clicks away and it would be even > quicker if there weren't the bug outlined here :-( > > There were times in which Mylyn was doing some exceptional things with the > Synchronize View, like the ability to automatically create and manage change > sets when the concept of change set was missing (like in CVS) or limited > (like in SVN). The "model" concept of the Synchronize View could probably be > used to easily switch between comparisons against different bases (since in > git we have the index, the HEAD, the FETCH_HEAD, remotes, etc. etc.); again, > with just a couple of clicks. It's really a pity it wasn't given priority :-( This additional layer of complexity which was implemented to hide missing features in the underlying versioning system is unnecessary for git.
(In reply to Matthias Sohn from comment #28) > I use Eclipse a lot but this doesn't prevent me from using additional useful > tools. > E.g. I use p4merge configured as git mergetool for complex conflict > resolutions. > Would also be nice to have a similar tool inside Eclipse but someone needs > to spend > the time to implement that. My days only have 24 hours, I am pretty busy > maintaining basic stuff in jgit and keep pace reviewing changes Thomas > writes faster > than I can review and try them ;-) Hi Matthias, sorry for the not-so-much-OT, but today I indeed bumped into Bug #482154. I see you mention p4merge here, which is also mentioned on that other bug. Once again, this is an example on how EGit is behind other older SCM features that used to work well in Eclipse and once again the use of an external tool is suggested... The world is moving towards Git, the fashion now says that centralized SCMs like Subversion are evil and that decentralized systems should always be used, there are valid points to state this and some other are less effective points IMHO, but fact is that nowadays Git is much more popular. Eclipse itself has dived into it, by leaving Subversive abandoned (after the only committer who was working on it got switched to other activities because Polarion was acquired) and pushing on JGit/EGit. Great effort has been made on these two projects (I must recognize it), but some key points of the original Eclipse Team Support, which were its strength IMHO, were substantially overlooked. Let me say once more that, from a long-time Eclipse user point of view, this is a pity. Here again, the requirement to use an external tool (p4merge) to overcome a clear bug in EGit (Bug #482154) which did not exist with older SCMs and which was reported more than 5 years ago, it's a not good sign IMHO. Don't get me wrong, mine is regret more than a criticism. It's just a fact that my experience with EGit so far has not been as much effective as it was with Subversion and CVS support in the past and this is just my 2cents to bring feedback to EGit maintainers.
