Community
Participate
Working Groups
Please see bug 342044 in the description on test case1.
if there is a conflict on a merged file , it is not human readable. For test case 1 in bug 342044 , we cant just compare file.txt VS HEAD. We should figure out a way to mark the file as conflicted and do smart comparing tell user how to merge.
The response from the /git/status is the same as for calling "git status" in a console. When a conflict occurred the file will be marked as added, changed, missing and modified at the same time. In the console this state is called as "both modified". I prepared a test case on the server side to verify this[1]. My guess is that the combination of these markers should result in the conflict being displayed on the client side. On the other hand, EGit uses a different approach for finding conflicts. It simply checks what stages the index file holds. If it's different than 0, it means it's a conflicting path. The test[1] verifies this as well. As for the "not human readable" content, an unmerged file will contain conflict markers (<<< === >>>), which are expected in this scenario. [1] http://git.eclipse.org/c/e4/org.eclipse.orion.server.git/commit/?id=c69083bcd790fbbab97334f3096434223ed635cd
