Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 361425 - Support patch workflow in Git
Summary: Support patch workflow in Git
Status: RESOLVED FIXED
Alias: None
Product: Orion
Classification: ECD
Component: Git (show other bugs)
Version: 0.3   Edit
Hardware: PC All
: P3 enhancement (vote)
Target Milestone: 0.4 M2   Edit
Assignee: Tomasz Zarna CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 365575 365576 367108
Blocks:
  Show dependency tree
 
Reported: 2011-10-19 11:56 EDT by Mark Macdonald CLA
Modified: 2012-01-09 07:30 EST (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Macdonald CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 2012-01-09 07:30:45 EST 
All blockers have been fixed.