Community
Participate
Working Groups
As described at comment 6 on bug 339045 , we had a simple solution in git status page to highlight a conflicting file. I've went through the 3 test cases described in bug 342044 and myself got completely lost on test case 2 and 3. 1.Both remote repo and local repo modified the saem file. 2.Remote repo modified and local repo deleted the same file 3.Remote repo deleted and local repo modified the same file To summarize , the git status responses gives 4 status the same file on test case 1 & 3 ,and 3 status on test case 2. As client side is filtering this "multiple status" case on every file in the response , once we know if 32 or 4 status happens on the same file , we flag it as conflicting in the git status page. Although the solution is kind of hacking , we can still live with it because we can see the red flag. But lets look at the further actions. My first reaction on the flagged files is to see the diff and that is the only way from the git status page for now. Please be aware that all the /git/diff/ response gives back multiple segments of diffs , where can only use one of them for the 2-way compare. In test case 1 , I had to use the first segment from /git/diff/Default/ response as it has the "<<<<<<<" and ">>>>>>" marks. Although not perfect but the diff tells me that the blocks with "<<<<<<<" and ">>>>>>" are conflicting places and I could manage to resolve them. In test case 2, /git/diff/Default/ gives me 2 segments of diffs but neither of them tells me why there is a conflict. The first segment tells me I am changing some thing and second one tells me I am deleting something. In test case 3, the second segment form /git/diff/Default/ response seems telling me the right diff but there is no internal criteria to know when I should use which segment.
My suggestion is to rework on test case 2&3 from server response and gives clear criteria on : 1.How to detect a conflicting file from git status response. 2.What diff should server respond to client even we are not using 3-way compare. If we do not resolve this , thee is no way for the user to know why there is conflict in test case 2 and 3.
(In reply to comment #0) > As described at comment 6 on bug 339045 , we had a simple solution in git > status page to highlight a conflicting file. > I've went through the 3 test cases described in bug 342044 and myself got > completely lost on test case 2 and 3. > > 1.Both remote repo and local repo modified the saem file. > 2.Remote repo modified and local repo deleted the same file > 3.Remote repo deleted and local repo modified the same file > > To summarize , the git status responses gives 4 status the same file on test > case 1 & 3 ,and 3 status on test case 2. > As client side is filtering this "multiple status" case on every file in the > response , once we know if 32 or 4 status happens on the same file , we flag > it as conflicting in the git status page. > > Although the solution is kind of hacking , we can still live with it because we > can see the red flag. > > But lets look at the further actions. > My first reaction on the flagged files is to see the diff and that is the only > way from the git status page for now. > Please be aware that all the /git/diff/ response gives back multiple segments > of diffs , where can only use one of them for the 2-way compare. > > In test case 1 , I had to use the first segment from /git/diff/Default/ > response as it has the "<<<<<<<" and ">>>>>>" marks. > Although not perfect but the diff tells me that the blocks with "<<<<<<<" and > ">>>>>>" are conflicting places and I could manage to resolve them. > > In test case 2, /git/diff/Default/ gives me 2 segments of diffs but neither of > them tells me why there is a conflict. > The first segment tells me I am changing some thing and second one tells me I > am deleting something. > > In test case 3, the second segment form /git/diff/Default/ response seems > telling me the right diff but there is no internal criteria to know when I > should use which segment. Sorry , I made too many typos in the description so please ignore the original description. Below id the clear description. ************************************************************* As described at comment 6 in bug 339045 , we had a simple solution in git status page to highlight a conflicting file and tell user why conflicts happened. I've gone through the 3 test cases described in bug 342044 and myself got completely lost on test case 2 and 3. Here are summaries of the test cases. 1.Both remote repo and local repo modified the same file. 2.Remote repo modified and local repo deleted the same file 3.Remote repo deleted and local repo modified the same file To summarize , the git status response gives 4 status of the same file on test case 1 & 3 ,and 3 status on test case 2. As client side is checking this "multiple status" case on every file in the response , once we know that 3 or 4 status happens on the same file , we flag it as conflicting and visualize it as red flag in the git status page. The solution is kind of hacking , but we can still live with it because we know which file is conflicting and needs to be resolved. But lets look at the further actions. My first reaction on the conflicting files is to see why they are conflicting. Diff is the only way from the git status page for me to do so. Internally , please be aware that all the /git/diff/ response gives back multiple segments of diffs , where I can only use one of them for the 2-way compare. In test case 1 , I had to use the first segment from /git/diff/Default/ response as it has the "<<<<<<<" and ">>>>>>" markers. Although not perfect but the diff tells me that the blocks with "<<<<<<<" and ">>>>>>" are conflicting places and I could manage to resolve them. In test case 2, /git/diff/Default/ gives me 2 segments of diffs but neither of them tells me why there is a conflict. The first segment tells me I am changing some thing and second one tells me I am deleting something. In test case 3, the second segment from /git/diff/Default/ response seems telling me the right diff but there is no internal criteria to know when I should use which segment.
Have to close this bug as the description is not clear. Opened bug 343198 to address it.
