Community
Participate
Working Groups
When I do Compare With Base Revision, my workspace file is on the left and the repository file is on the right. This is a bit counter-intuitive for some people, and differs from similar tools such as P4. Essentially, this should be configurable via user preference and have a button next to the 'change copy' buttons to switch on the fly.
Sighted in 3.4.
At some point in time the choice of what side the local/remote contents should be on was made. I belive it was arbitrary. From my point of view making the editor configurable sounds like a good idea, but I think Michael is more eligible than me to comment on that.
Well I agree that it would be nice to allow the user to configure which side is local, I suspect it would be a fair bit of work to find all the places that depend on this assumption. I don't agree that having the local of the left is counter-intuitive since the choice is, in essence, arbitrary. However, I suspect you were just trying to say that some people are used to seeing the local on the right side and it would be easier for them if they could configure all the tools they use to use the same arrangement (Out of curiosity, is P4 configuration in this way?).
Well, I view Compare in source control as the passage of time, one object changing to another, and being in a left-to-right culture, I probably prefer that to be left-to-right. That's just me personally though. The P4 I last used was local-right by default, so I never checked if it was configurable. A straw poll here indicates a 50/50 split, so while it might be a lot of work, I think it might be worth it, as it's making life difficult for half the users.
By "left-to-right culture" I assume you are referring to writing. I afraid I don't see the connection between that and whether the local contents are on the left or right but that's just my opinion. Also, I think you are over estimating the issue. I would say it was less than 1% of users who care about this but again, that's just my opinion. If you feel strongly about this then, by all means, take a crack at preparing a patch.
I must agree with Michael, I wouldn't say that the problem touches half the users. Most of the roads have two lanes, but it doesn't mean you can drive on both of them. There are some rules. You usually drive on the right side, unless you go to UK, but that's a different story... So, I would never say that half of the drivers would like to drive on the left side ;) Anyway, as Michael suggested, a patch is welcome. Software world is more flexible than the real one.
*** Bug 347055 has been marked as a duplicate of this bug. ***
Any other side-by-side diff viewer I know shows the repository state (old state) on the left and the local state (new state) on the right: - WinMerge - SmartGit - Opendiff - Vimdiff - MediaWiki, to name a wiki tool I really don't understand why Eclipse is different here and this feature has actually kept me from using the Eclipse diff viewer so far, as I can’t manage to switch my brain between Eclipse mode and rest-of-the-world mode when reviewing changes. An option to change this would be very much appreciated.
Also please note that the preview dialog of the Eclipse refactoring tools features the "Original Source" on the left and the "Refactored Source" on the right. This is fine, and Eclipse's regular diff viewer is inconsistent with that. If made configurable, then IMHO the configuration should consistently apply to the diff viewer, the refactoring preview, and any other place in Eclipse where an old version is compared to a new version.
Two notes to comments from M. V. 2008-01-03 13:07:03 EST + T. Z. 2008-01-04 09:13:32 EST who both argue against (at least not in favor to) the issue. Michael does not see the connection between left-to-right culture of writing and whether the local contents are on the left or right. The (strong) connection is this: By writing left to right what's written to the left (on a line) is written earlier than what's written to the right. So when comparing revisions I would prefer this to be reflected, that is to have the earlier revision on the left and the newer revision (or workspace file) on the right. Tomasz observes that we usually/mostly drive on the right side, and that he (therefore) agrees with Michael. But that observation is an argument _for_ the issue: We exactly want to have our stuff (the local workspace file, the newer revision) on the right side.
Mirroring Martin's perspective, I'm also more accustomed to the left-to-right style, and it is the style I've seen in most of the version-control tooling I've used in the past. So, the default right-to-left displayed by Eclipse is incredibly foreign and frustrating to me. Just as with Martin, this has meant I avoid the diff facilities within Eclipse like a plague. There was a bit of talk that the preferences for one way or the other is 50/50. Others have felt that only less than 1% of people actually care. My perspective, if your work environment consists of colleagues that are all conditioned to left-to-right diff'ing and you enforce the opposite, you've put an entire workplace offside with your product. To me, this issue isn't a 1% trivial issue, perhaps more 50/50, or if I look back on all the colleagues from past workplaces and assessed what style they used, it was predominantly left-to-right, I only ever met one colleague that preferred right-to-left, so for me, this issue feels more like 90/10, in the favour of left-to-right. But who knows, perhaps there are workplaces where right-to-left is more prevalent, and I've just never worked in those places before. So yes, would be nice to have an option to choose.
Every comparison or merge tool I have ever used places older content on the left and newer content on the right. This includes Web-based tools; for example, it is how Wikipedia displays differences: http://en.wikipedia.org/wiki/Help:Diff Eclipse is the first tool I have ever seen that places newer content on the left and older content on the right. I'm surprised that the results of any straw poll would even approach 50/50, but if that is the case, I suspect the sample is not representative of the industry. Please, at least make this a configurable option!
I agree that the old version should be displayed on the left side and the new version on the right side.
It feels like the "right" thing to do would be to detect the text-direction of the current locale's language/script and make the right ltr-vs-rtl decision. I know of no other utility that puts the "older" version on the right-hand side when doing side-by-side diff displays, but that may be due to my English-language and therefore ltr-bias.
A agree with all arguments for putting the new (local) version to the right. It is really hard to use Eclipse diff when all other diff viewers use opposite logic. Color support in diff viewer is also significantly lower than in specialized viewers. I prefer Meld among others in Linux world and TortoiseDiff on Windows. It would be nice if Eclipse take inspiration in some "state of the art" tools. I would also appreciate an option to switch on unified diff format.
I honestly can't get my brain to work with the flipped-sides-compare and therefore I'm simply not able to use compare in Eclipse. I agree on most of the pro arguments (Comment 1, Comment 4, Comment 8, Comment 10, Comment 11 and Comment 12) which basically is: 1. Comments assuming it has to do with the reading direction: when I commit source code I review all my changes thinking something like "this (base) is becoming that (change)" as opposed to presumably something like "this (change) was made out of that (base)". As a reply to Comment 14 I'd say yes, it might have to do with the reading direction, but no, you don't know the way a developer rethinks the changes (the two examples are both left to right). 2. It's different from all other tools I'm aware of (absurdly including Eclipse tools): you can't get fast when the views change with every tool. See also: http://stackoverflow.com/questions/99830/eclipse-text-comparison-order http://stackoverflow.com/questions/9340782/how-to-switch-the-order-of-files-original-and-modified-in-eclipse-compare-wind ...
It is unbelievable Eclipse is the only tool I have ever seen to do it in this order. A year ago we chose against using EGit with this being one of its issues. Now I see EGit has improved a lot, but having to bring this to mind every single time I open a diff (essentially on every commit etc) is a no-go. If there is no seriously good reason to do it this way, contrary to every other tool out there it should not be done this way. And I have not seen such a reason. Quite the contrary.
Seeing that this issue has been open for several years now, I was starting to wonder what it would take to escalate it in priority. Presently, there are 24 votes for it, so I thought that might give it some weight. I had a read over a bug-thread where people had discussed turning the bugzilla voting-system on: https://bugs.eclipse.org/bugs/show_bug.cgi?id=12115 They eventually got what they wanted (voting was turned on), but it was also interesting to see the differing views, some people felt it should affect priority, others didn't and said let the developer decide for themselves. There was also a mention of a developer being assigned to 458 bugs, so I can sympathise that tackling that many bugs is going to take time, no matter how you prioritise them. I also consider the weight of the comments shared in this thread as a type of "vote" too, from a variety of people, not just one person preaching their own agenda. The majority of which are in support of this getting this point rectified. Perhaps it'd be nice if the assigned developer could give us some feedback here on their perspective, how this weighs up against other bugs on their plate. Eg, are they seeing it as high-low priority? The "Importance" field is presently set to "P4 enhancement". I've read online that [p1]=Most Important, and [p4]=Least Important. Is this a reasonable level? I suppose to the people commenting and up-voting this bug, it probably doesn't feel like it. But to be fair, I don't know how it stacks up against all the other bugs the developer is assigned to. Perhaps the developer genuinely has bigger fish to fry at this point in time. Then again, if they've got 400 or so bugs on their plate, perhaps us waving our arms up and down (well, not literally:)) and drawing attention to our bug-of-interest isn't such a bad thing? Anyway, just wanted to mull over and share some thoughts.
I don’t think “Platform-Compare-Inbox” is a real developer. My main problem here is that there was not even a clear "yeah, this should be done - feel free to implement this option". Instead, I felt like the developer argument was "leave as is". But I guess @Michael Valenta was pretty welcome to providing patches. > If you feel strongly about this then, by all means, take a crack at preparing a patch. Not sure what > I suspect it would be a fair bit of work to find all the places that depend on this assumption points at, but scares me a bit. Is someone familiar with the Eclipse codebase or ecosystem? Or can give some starting points where to implement this feature and provide a patch?
I also wonder what the “helpwanted” keyword means. "Feel free to contribute"?
Indeed: > helpwanted: Indicates that the committers are requesting help in working on this bug.
OK spend 15 minutes browsing the Eclipse help and source to see if I can provide some kind of starting point. Note though that I'm not really that familiar with the codebase. I think the target package is: [org.eclipse.compare](http://help.eclipse.org/luna/index.jsp?topic=%252Forg.eclipse.platform.doc.isv%252Freference%252Fapi%252Forg%252Feclipse%252Fcompare%252FCompareConfiguration.html) The target class: [CompareConfiguration](http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcompare%2FCompareConfiguration.html) [code](http://grepcode.com/file/repository.grepcode.com/java/eclipse.org/3.7/org.eclipse/compare/3.5.200/org/eclipse/compare/CompareConfiguration.java) I couldn't discover much more in this short time. There is a private static boolean called fLeftIsLocal, which is set to true. Though upon inspection it seems only to set some images.
See also bug 457111.
New Gerrit change created: https://git.eclipse.org/r/75955
(In reply to Eclipse Genie from comment #24) > New Gerrit change created: https://git.eclipse.org/r/75955 Conrad, this looks interesting. Thanks for working on this! Do you think we can use same approach in egit (bug 457111)? I have not yet tried this within IDE, but if you would propose similar patch for egit, we can review & merge pretty fast. Unfortunately I have no commit rights for platform team repo, but I have them for egit ;)
(In reply to Eclipse Genie from comment #24) > New Gerrit change created: https://git.eclipse.org/r/75955 I'll review the patch shortly.
(In reply to Andrey Loskutov from comment #25) > (In reply to Eclipse Genie from comment #24) > > New Gerrit change created: https://git.eclipse.org/r/75955 > > Conrad, this looks interesting. Thanks for working on this! Do you think we > can use same approach in egit (bug 457111)? I have not yet tried this within > IDE, but if you would propose similar patch for egit, we can review & merge > pretty fast. Unfortunately I have no commit rights for platform team repo, > but I have them for egit ;) I had a short look into the egit code and I think, it doesn't need an extra patch because it uses the org.eclipse.compare.contentmergeviewer.ContentMergeViewer, which now can toggle the left and right input for display. The model values for left and right are not changed. I already tested my patch with the GIT Staging view (compare HEAD with local revision) and History view (compare a revision with its parent revision).
By the way: - The compare editor preview on the preferences page dynamically reflects the toggle checkbox state. - Changing the toggle checkbox state in the preferences affects all open compare editors.
The preference is slightly confusing in its current form since the word "toggle" doesn't apply to a check box. It would be preferable to replace it by a pull-down list -- Display: Local on the left/Local on the right, or Display: Traditional/Natural.
I can go with the suggested renamings. But I see a problem with the terms local, remote, incoming and outgoing in this context, as we are talking about the default eclipse compare editor, which may be used in various different scenarios. One use case are the team providers, which offer the possibility, to compare the local edition of a file with the HEAD revision (called remote in this case). Another use case is, to compare two files with each other. In that context you don't have a local or remote, you just have to ordinary files. I suggest to rename Toggle to Flip in the whole patch.
Horizontal radio buttons never look particularly good, but making them vertical would take too much space. Any objections against a pull down list? Compare layout: Traditional/Natural An advantage of this approach is that it gives the layout compatible with Gerrit and friends an attractive name.
(In reply to Sergey Prigogin from comment #31) > Horizontal radio buttons never look particularly good, but making them > vertical would take too much space. Any objections against a pull down list? > > Compare layout: Traditional/Natural > > An advantage of this approach is that it gives the layout compatible with > Gerrit and friends an attractive name. I've answered on Gerrit. Let us continue the discussion there?
Created attachment 262733 [details] Switch left and right view in TortoiseGitMerge
Created attachment 262734 [details] Swap Panes in WinMerge
Gerrit change https://git.eclipse.org/r/75955 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=ec30f62a24da6e8e47dbb3a566049c628bb74f05
Thank you for the quality patch. I've flipped the default to make it match Gerrit and most other tools. Will soon request backporting to Neon.1.
Thanks Conrad for the patch. Sergey or Conrad can you a add an entry to to the note and noteworthy of 4.7 M1?
This change caused many test fails in SDK build, see http://download.eclipse.org/eclipse/downloads/drops4/N20160711-1329/testResults.php
(In reply to Sergey Prigogin from comment #36) > Thank you for the quality patch. I've flipped the default to make it match > Gerrit and most other tools. Will soon request backporting to Neon.1. Looking at the failing tests, I would separate the change in two: 1 allow compare configuraton 2 change the defaults and only backport 1) to 4.6.1. No one expects from a maintenance release that radical change, and switching sites is one click away, so even if default is not changed, the feature is easy to use.
New Gerrit change created: https://git.eclipse.org/r/77199
Gerrit change https://git.eclipse.org/r/77199 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=73fd0ef44b36fd04a8268b9600d4f21f91a43381
The tests should be OK now. Will wait for a nightly build before closing the bug.
The tests are passing.
Sergey, any update on the N&N entry?
This change needs rework, see bug 498151. I would not waste time writing an N&N entry at this time.
New Gerrit change created: https://git.eclipse.org/r/77571
Reverted due to the following problems: 1. In the left-to-right mode the toolbar shows wrong buttons - Copy All Non-Conflicting Changes from Right to Left instead of Copy All Non-Conflicting Changes from Left to Right and Copy Current Change from Right to Left instead of Copy Current Change from Left to Right. The shown buttons are disabled since they don't apply to the left-to-write mode. 2. Clicking on the Switch Left and Right View in a Compare editor doesn't change the underlying preference, which means that the current state of the editor is not preserved after closing and reopening.
Gerrit change https://git.eclipse.org/r/77571 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=d1a02b5588da41cf909755d308bae2f640998ce3
*** Bug 498151 has been marked as a duplicate of this bug. ***
(In reply to Sergey Prigogin from comment #47) > Reverted due to the following problems: ... Using Left-to-right and Right-to-left should also be avoided since this is used for BiDi. It's also not clear what's right and what's left.
(In reply to Dani Megert from comment #50) > It's also not clear what's right and what's left. Very puzzling statement. Dani, do you mind to explain what is not clear about the terms "left" and "right"?
(In reply to Sergey Prigogin from comment #51) > (In reply to Dani Megert from comment #50) > > > It's also not clear what's right and what's left. > > Very puzzling statement. Dani, do you mind to explain what is not clear > about the terms "left" and "right"? IIRC this comment referred to the added preference UI, but can't say for sure without looking at this again.
New Gerrit change created: https://git.eclipse.org/r/78565
Sorry for my last patch, which was indeed not feature-complete. I totally missed the fact, that one or both sides of the compare view can be editable. (In reply to Sergey Prigogin from comment #47) > 1. In the left-to-right mode the toolbar shows wrong buttons - Copy All > Non-Conflicting Changes from Right to Left instead of Copy All > Non-Conflicting Changes from Left to Right and Copy Current Change from > Right to Left instead of Copy Current Change from Left to Right. The shown > buttons are disabled since they don't apply to the left-to-write mode. Working in the new Gerrit change. > > 2. Clicking on the Switch Left and Right View in a Compare editor doesn't > change the underlying preference, which means that the current state of the > editor is not preserved after closing and reopening. That was by intent. The switch button only affects the corresponding compare view and not the global property. The switch button is now a toggle button. TODO: Test junit result compare ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=498151#c3 )
Created attachment 263486 [details] Screenshot Result Comparison
Created attachment 263487 [details] Screenshot Result Comparison with Switch Button
(In reply to Conrad Groth from comment #54) > TODO: Test junit result compare ( > https://bugs.eclipse.org/bugs/show_bug.cgi?id=498151#c3 ) I tested the result comparison, which now also uses the global "Swapped" property. See attachment 263487 [details].
New Gerrit change created: https://git.eclipse.org/r/78652
Gerrit change https://git.eclipse.org/r/78652 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=197e7f029ecc8b5217ce226bac3b4379df49c115
(In reply to Conrad Groth from comment #57) Issues with the patch https://git.eclipse.org/r/#/c/78565/: 1. Wrong behaviors of the Copy All Non-Conflicting Changes from Right to Left button. To reproduce: - Create a local file with a few lines - Delete a line - Compare With > Local History - Double-click on the original version in the History view. The Copy All Non-Conflicting Changes from Right to Left button is enabled. - Click on Switch Left and Right View The Copy All Non-Conflicting Changes from Right to Left button is supposed to be replaced by Copy All Non-Conflicting Changes from Left to Right, but instead of being replaced, the button just gets disabled. - Click on Switch Left and Right View again Copy All Non-Conflicting Changes from Right to Left gets replaced by Copy All from Left to Right, which is incorrect. 2. There is an asymmetry between the the Swap sides checkbox in the preference page and the Switch Left and Right View button. Changing the preference changes the default state of the button for newly opened Compare editors, but not vice versa. Changing the preference flips the panes in an already open Compare editor, but doesn't change the state of the Switch Left and Right View button. 2. The switch icons should be taken from https://git.eclipse.org/r/#/c/75955/8
(In reply to Sergey Prigogin unavailable until August 16th from comment #60) > 1. Wrong behaviors of the Copy All Non-Conflicting Changes from Right to > ... Fixed > 2. There is an asymmetry between the the Swap sides checkbox in the > ... Still open > 2. The switch icons should be taken from > https://git.eclipse.org/r/#/c/75955/8 Done
Gerrit change https://git.eclipse.org/r/78565 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=d123d8ceecaefa3b677f09e81c09e642a4e988cd
Thank you, Conrad.
There are API Tools problems: https://wiki.eclipse.org/Version_Numbering#API_Baseline_in_API_Tools
(In reply to Markus Keller from comment #64) > There are API Tools problems I just realized that these are probably new in I20160906-0800 and could need a second thought in API Tools. Bugzilla is currently too slow to analyze the history of these problems. Will reopen if there's really anything to do.
New Gerrit change created: https://git.eclipse.org/r/80730
Gerrit change https://git.eclipse.org/r/80730 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=24b14a1bb0b35572cbc84ba4d0a1c6f7677473f3
Hi! Thanks for this great feature! I've been thinking: since this is the kind of thing that the user would likely only have to set once, would it make sense to only have it in the Preferences dialog and not as a toolbar button?
(In reply to Marc-Andre Laperle from comment #68) > kind of thing that the user would likely only have to set once, would it > make sense to only have it in the Preferences dialog and not as a toolbar > button? A week -1 from me for this proposal. Such a preference would rarely be discovered by the user and IIRC there were objections to change the default default.
(In reply to Lars Vogel from comment #69) > A week -1 from me for this proposal. Such a preference would rarely be > discovered by the user and IIRC there were objections to change the default > default. The objections for changing the default were based on API not on end-user benefit. Since end user benefit trumps all other considerations, the proposal for changing the default and removing the button should be considered. Marc-Andre, would you mind filing a feature request to gouge people's opinions.
(In reply to Sergey Prigogin from comment #70) > (In reply to Lars Vogel from comment #69) > > A week -1 from me for this proposal. Such a preference would rarely be > > discovered by the user and IIRC there were objections to change the default > > default. > > The objections for changing the default were based on API not on end-user > benefit. Since end user benefit trumps all other considerations, the > proposal for changing the default and removing the button should be > considered. Marc-Andre, would you mind filing a feature request to gouge > people's opinions. I created bug 501752.
Requesting PMC approval for backporting to 4.6.2.
(In reply to Sergey Prigogin from comment #72) > Requesting PMC approval for backporting to 4.6.2. I didn't look into the changes. Do they contain API changes/additions? If not, you only need the approval from the project lead and the change against R4_6_maintenance must be reviewed by someone who did not make the changes. If yes, you need to send a note to the eclipse-pmc mailing list explaining why the API changes are required and useful.
New Gerrit change created: https://git.eclipse.org/r/82301
Gerrit change https://git.eclipse.org/r/82301 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=113da94aad098175fcc200a664fd8cd2ed18a51c
(In reply to Dani Megert from comment #74) Here is a list of the added APIs: org.eclipse.compare.CompareConfiguration: /** * Name of the mirrored property, i.e. if left input is shown on the right side and vice versa. * @since 3.7 */ public static final String MIRRORED = "MIRRORED"; //$NON-NLS-1$ /** * <b>Only the views are mirrored. All model values for left and right are not changed!</b> * * @return true if the left and right side of the viewer are mirrored. Default is false. * @since 3.7 */ public boolean isMirrored() org.eclipse.compare.contentmergeviewer.ContentMergeViewer /** * If the inputs are mirrored, this asks the right model value. * * @return true if the left viewer is editable. * @since 3.7 */ protected boolean isLeftEditable() /** * If the inputs are mirrored, this asks the left model value. * * @return true if the right viewer is editable. * @since 3.7 */ protected boolean isRightEditable()
(In reply to Sergey Prigogin from comment #77) > (In reply to Dani Megert from comment #74) > Here is a list of the added APIs: OK. I don't see a problem with this, but please post to eclipse-PMC in order to follow the official process.
(In reply to Dani Megert from comment #78) > (In reply to Sergey Prigogin from comment #77) > > (In reply to Dani Megert from comment #74) > > Here is a list of the added APIs: > > OK. I don't see a problem with this, but please post to eclipse-PMC in order > to follow the official process. I see you already did. I should have processed my regular e-mail before bugzilla e-mails ;-).
New Gerrit change created: https://git.eclipse.org/r/82336
New Gerrit change created: https://git.eclipse.org/r/82335
Gerrit change https://git.eclipse.org/r/82335 was merged to [R4_6_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=d12c403fa89f023f6e29425649bab0780712002c
Gerrit change https://git.eclipse.org/r/82336 was merged to [R4_6_maintenance]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.team.git/commit/?id=1c55cf8516cc81a3d4ddcbb0c970af54afcf161f
The code changes have been cherry-picked to the R4_6_maintenance branch. Two questions: 1. What to do with the N&N section describing the feature? The news git repository doesn't have R4_6_maintenance branch. 2. Should the service version of the org.eclipse.compare plugin be incremented on the master branch to distinguish it from the R4_6_maintenance branch?
(In reply to Sergey Prigogin from comment #84) > The code changes have been cherry-picked to the R4_6_maintenance branch. > > Two questions: > 1. What to do with the N&N section describing the feature? The news git > repository doesn't have R4_6_maintenance branch. So far we did not have an N&N for service releases. > 2. Should the service version of the org.eclipse.compare plugin be > incremented on the master branch to distinguish it from the R4_6_maintenance > branch? Yes. This will give you API Tools warnings or errors. Those should be suppressed.
*** Bug 457111 has been marked as a duplicate of this bug. ***
*** Bug 344063 has been marked as a duplicate of this bug. ***
