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

Bug 361425

Summary:	Support patch workflow in Git
Product:	[ECD] Orion	Reporter:	Mark Macdonald <mamacdon>
Component:	Git	Assignee:	Tomasz Zarna <tomasz.zarna>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	libingw, Szymon.Brandys, tomasz.zarna
Version:	0.3
Target Milestone:	0.4 M2
Hardware:	PC
OS:	All
Whiteboard:
Bug Depends on:	365575, 365576, 367108
Bug Blocks:

Description Mark Macdonald

2011-10-19 11:56:56 EDT

Orion 0.3RC2

The other day I needed to review a patch attached to a bug. I had to go back to the command-line Git client for this, since there's no way to apply a patch using the Orion git tools.

Comment 1 Tomasz Zarna

2011-10-20 09:57:38 EDT

Yup, definitely a cool feature. Saving Git Status as a patch would be useful too. Saving any comparison actually (see bug 71374).

Comment 2 Szymon Brandys

2011-11-03 07:20:38 EDT

It would be good to have bug 361548 fixed first. However another approach is to just use our Eclipse Compare Framework as Tomek mentioned in bug 361548, comment 0. Tomek, I think it will be better to rely on our framework for now than on a bug out of the JGit dev plan. Especially that our Orion bug is targeted for .4.

Comment 3 libing wang

2011-11-18 09:00:04 EST

In Orion compare widget, there is an internal api that generates new file based on the input file and the unified diff. Not sure if this will be another option.

Comment 4 Tomasz Zarna

2011-11-18 09:31:56 EST

(In reply to comment #3)
> In Orion compare widget, there is an internal api that generates new file based
> on the input file and the unified diff.

Would you interested in switching that to work on the server response?

> Not sure if this will be another option.

Keeping them both (patching mechanism on the client and on the server) wouldn't be bad, as long as they always produce identical results.

Comment 5 libing wang

2011-11-18 10:03:28 EST

(In reply to comment #4)
> Would you interested in switching that to work on the server response?
Not sure if I understand this correctly. Did you mean converting the  JS code to java?

Comment 6 Tomasz Zarna

2011-11-18 10:29:23 EST

(In reply to comment #5)
>  Did you mean converting the  JS code to java?

No, I meant to use the server response instead of the result of the JS code. Or actually, use the server response *in* the JS code of yours.

Comment 7 libing wang

2011-11-18 11:12:22 EST

(In reply to comment #6)
> (In reply to comment #5)
> >  Did you mean converting the  JS code to java?
> 
> No, I meant to use the server response instead of the result of the JS code. Or
> actually, use the server response *in* the JS code of yours.

Yes,  I am doing it now.
Before the new file was always generated by old file + diff. I thought it would reduce one request from server ( the new file content) but indeed we do not have to.
As I am doing client side diff any way(compare any files where server can't respond a diff), I will leave that function for future use.

Comment 8 Tomasz Zarna

2012-01-09 07:30:45 EST

All blockers have been fixed.