Bugzilla – Full Text Bug Listing
| Summary: | [server] 3-way compare API support | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | libing wang <libingw> |
| Component: | Git | Assignee: | Project Inbox <orion.git-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | bokowski, evan_hughes, Szymon.Brandys |
| Version: | 0.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 344848 | ||
| Bug Blocks: | 339045, 364851 | ||
|
Description
libing wang
Before I start investigating what options JGit gives us, I would like to know what kind of response (content and format) would be the best from your point of view. Is set of diffs better then just sending you files content? Are your preferences the same for cases 1. and 2.? (In reply to comment #0) > 1.Before merge(same as cvs sync) :During structural compare (bug 342977) , on > the file that is marked as conflicting but not yet merged. In this case I don't think sending file contents (left, right and base) would help you display a 3-way compare. Same thing for diffs, neither left-base, right-base, left-right (this is actually 2-way compare we already have). What we actually need is something similar to what org.eclipse.compare does with results from LCS[1]. It combines[2] two (left-base and right-base) two-way compare results and decides when only left changed, when right and when it's a conflicting change. A diff with this kind of markers could be use to display a 3-way compare. Makes sense? Obviously, only one side of the editor should be writable i.e. "ours". > 2.After merge(same as cvs update) : In the git status page , on the file that is > already merged and marked as conflicting.Currently , client side is computing > the conflict by the multiple status .We should also redesign this on server > side.(bug 343198). > > In case 2 ,depending on how Jgit will support , I am not sure it is too late to > do 3-way compare but we should REALLY need a solution. You're right, it is too late. The 3-way merge has been already done and we're left with unresolved conflicts. All we can do is to display them side by side (parse these awful '>>>>>' markers) to help user merge them manually. Of course, we could apply the idea mentioned above here, but the result would be basically the same: a diff with all changes marked as conflicts. Again, only one side of the editor should be writable i.e. "ours". [1] org.eclipse.compare.internal.core.LCS [2] org.eclipse.compare.rangedifferencer.RangeDifferencer.findDifferences(AbstractRangeDifferenceFactory, IProgressMonitor, IRangeComparator, IRangeComparator, IRangeComparator) During structural compare , we should give two options to the user for comparing 1.Left-right pattern : we will mark the incoming , outgoing and conflicting blocks just as eclipse desktop does. This will be the default behavior.There will be an action to bring up pattern 2 inside the compare editor. 2.Left-middle-right pattern , where the common ancestor sits in the middle.In this option ,"my change VS ancestor" and "other's change VS ancestor" will be represented. We may need 2 sets of server APIs to support this respectively. (In reply to comment #3) > 2.Left-middle-right pattern , where the common ancestor sits in the middle.In > this option ,"my change VS ancestor" and "other's change VS ancestor" will be > represented. see bug 344848 According to http://wiki.eclipse.org/Orion/Milestone_Plan it has been deferred. Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html |