Community
Participate
Working Groups
If you have a merge situation, the git-status page doesn't quite work right, and the compare viewer does not display the right thing. On the command line, I currently see something like this: # Unmerged paths: # (use "git add/rm <file>..." as appropriate to mark resolution) # # deleted by them: js/sites/widgets/templates/SiteConfigEditor.html (there are many other possible merge situations - this is one where I made changes to a file that got deleted by someone else) We should understand what the current behaviour is in all merge cases, and if there's a potential for users to lose work. If we find a case, we should do something for M6 that won't lose work. For M7, we need to support the merge case, including a compare viewer and a merge editor that can handle three-way diffs.
I should add that in my current example, git-status.html shows the same file twice (as unstaged) - once with the "deleted" icon, and once with the "changed" icon. When I click on either of the two, I see the same diff in the inline compare viewer, and the diff looks as if the diff format wasn't parsed correctly.
I think a good start point of the solution is : 1. Server provides a flag which file has conflict. 2. Server provides the common ancestor for the conflicts Not what the best solution on the UI side is but at least we need : 1.If there is a common ancestor , we may want two sets of diffs for the user to easily merge. 2.If there is no common ancestor detected , we should figure out a way to tell where the conflict is and let the user use two way compare editor.
Had a conversation with Szymon today. The work flow he suggested is : 1. you have Navigator UI, Status UI, Push/Pull UI 2. you do changes in Navigator UI, then go to Status UI to stage changes and commit 3. then go to Push/Pull UI to push them 4. now, you use Pull on the Push/Pull UI 5. some changes are automatically merged, some need your attention 6. files that need a merge should be flagged somehow, so when go back to Navigator UI, we can find them and merge manually 7. when we do this, we go back to Status UI, and we know which files need a manual merge. 8. do manual merge by 3-way editor (UI design not yet determined) 9 . we stage merged files and we are done. bug 339722 already addressed the Push/Pull UI.
opened bug 342044 to track all the test cases for merge.
this bug depends on bug 342179. Had conversation with Szymon and Tomasz yestoday. From what Szymon agreed with Boris , in M7 we will not support the three-way compare. We will just use the file with special conflict markers (described as the last comment from bug 342179) and will do some special markers on the client side.
after talked to Tomasz again , here is the deal for a conflict file in git status page for M7. 1. the server response will remain the the same as addressed in bug 342179. Server returns 4 items for conflict file , marked as added,changed,missing and mod. 2. Client will filter out files file with 4 states , mark it as conflicted and only render once at the unstaged category. 3. The diff on the conflicted file from server side includes multiple segments (described in test case 1 @ bug 342044. Client will just use the first segment , which reflects the real diff of conflicted file VS HEAD. 4.In the compare editor , all the diff blocks are treated as normal diff. (There is possibility to color all conflicted blocks as red but the implementation affects the diff parser greatly so I have to decide later) 5. For the "stage " action on a conflicted file , it equals to "resolve conflict". Once it is staged , jgit treats it as non-conflict. Not sure how hard it will be to show the conflicting file in the navigator(response from a file meta data ?) but I will open a bug for that.
fixed with 9f2dd0e53b45e45e02b5e878a42f3667d967722f. Solution is described as last comments. Also opened bug 342873 for the navigator to mark the conflicted file.
as test case 2 and 3 from bug 342044 are not clearly resolved , I am reopening this bug. bug 343192 was opened to improve the server response.
we will close this after 3-way compare is resolved but not for 0.2.
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
