Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 342179

Summary:	[server] Git status gives strange response on a merged file with conflicts and so does Diff
Product:	[ECD] Orion	Reporter:	libing wang <libingw>
Component:	Client	Assignee:	Tomasz Zarna <tomasz.zarna>
Status:	RESOLVED WORKSFORME	QA Contact:
Severity:	normal
Priority:	P3	CC:	Szymon.Brandys
Version:	0.2
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description libing wang

2011-04-07 11:11:48 EDT

Please see bug 342044 in the description on test case1.

Comment 1 libing wang

2011-04-11 11:57:15 EDT

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.

Comment 2 Tomasz Zarna

2011-04-12 07:06:03 EDT

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