Bugzilla – Full Text Bug Listing
| Summary: | From repo history, compare with each other shows files in wrong order | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Marc Khouzam <marc.khouzam> | ||||||
| Component: | UI | Assignee: | Project Inbox <egit.ui-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | amj87.iitr, kresimir, matthias.sohn, remy.suen, robin, sam.davis | ||||||
| Version: | 1.0 | ||||||||
| Target Milestone: | 2.0-M2 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Marc Khouzam
I'm running EGit 1.0.0.201106090707 What I see: Left: * newer commit id * newer content Right: * older commit id * older content But I wonder if we really want to have this order, I'd rather switch the sides and have the newer on the right. Matthias, any input on this? Created attachment 200351 [details] Screenshot of error (In reply to comment #2) > What I see: > > Left: > * newer commit id > * newer content > > Right: > * older commit id > * older content That is not what I see. I attached a screenshot that shows the situation where I get Left: * newer commit id * older content Right: * older commit id * newer content It is tricky to know where the new/old content is, but since I made the commit, I can tell that the new code that I wrote is on the right pane. > But I wonder if we really want to have this order, I'd rather switch the sides > and have the newer on the right. I prefer new on the right also, but I believe the usual Eclipse order is "left is new". That is what the other projects seem to do for compares. Used a simple repo (one file, each commit increased a number in the file to easily reproduce it). Will test with the CDT repo if I can reproduce it there. Created attachment 200359 [details]
Related error about file being added?
I noticed a potential other bug that could be caused by this issue.
If you look at the screenshot attached, you will see that a minus sign decorator is being used on a file that was actually added by the commit. I believe this should be a plus sign decorator.
I thought it could be caused by the fact that the contents are reversed and makes it look like the file was removed?
If you feel it should be a new bug, let me know and I'll open it.
Thanks
Pushed a fix for this: https://git.eclipse.org/r/5182 *** Bug 365352 has been marked as a duplicate of this bug. *** I just realized that EGit also shows changes on the wrong side whenever there are conflicts. The convention is to show your local version on the left, which is what EGit does when there are no conflicts. When there are conflicts though, EGit shows your local version on the right. No wonder I find the merge tool so confusing! I think what's happening here is that in the middle of a rebase, your previous local commit is seen as "incoming" by Git, but from the user's perspective this is totaly backwards and confusing. The mangled file that Git produces during the rebase also has "<<<<<<< OURS" and ">>>>>>> THEIRS" reversed. merged as 22fb77bb91670dc4bb0c5252a0302885c942445f (In reply to comment #8) > I just realized that EGit also shows changes on the wrong side whenever there > are conflicts. The convention is to show your local version on the left, which > is what EGit does when there are no conflicts. When there are conflicts though, > EGit shows your local version on the right. No wonder I find the merge tool so > confusing! > > I think what's happening here is that in the middle of a rebase, your previous > local commit is seen as "incoming" by Git, but from the user's perspective this > is totaly backwards and confusing. The mangled file that Git produces during > the rebase also has "<<<<<<< OURS" and ">>>>>>> THEIRS" reversed. @Sam: report this as a separate bug in order not to make this a never ending story. I've created the following bug: 376223: EGit shows changes on the wrong side whenever there are conflicts https://bugs.eclipse.org/bugs/show_bug.cgi?id=376223 *** Bug 385614 has been marked as a duplicate of this bug. *** *** Bug 360384 has been marked as a duplicate of this bug. *** |