Bugzilla – Full Text Bug Listing
| Summary: | [server] Provide REST API for git status and diff | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Tomasz Zarna <tomasz.zarna> |
| Component: | Client | Assignee: | Tomasz Zarna <tomasz.zarna> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | bokowski, caniszczyk, john.arthorne, libingw, Szymon.Brandys |
| Version: | 0.2 | ||
| Target Milestone: | 0.2 | ||
| Hardware: | PC | ||
| OS: | All | ||
| URL: | http://wiki.eclipse.org/Orion/How_Tos/Working_with_git | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 334206, 336116, 338225 | ||
|
Description
Tomasz Zarna
Chris, are you aware of any related work? There's a bug open in JGit to provide a nicer API for diff than using the low-level internals... Bug 334766 - Add DiffCommand to JGit API If you don't mind using low-level code in JGit, you can look at how we implemented diff in the CLI code... /org.eclipse.jgit.pgm/src/org/eclipse/jgit/pgm/Diff.java For status, it's a tad trickier but you can look at how we do it when we decorate resources in the navigator... o.e.egit.ui.internal.decorators.DecoratableResourceHelper.decorateResource(...) If you need help with this, I'm willing to get my hands dirty. I recently setup Orion development on my new Macbook Air :D Thanks for the tip Chris, I came to the exact same conclusion when looking at the code today. I just hope we will be able to stick to the JGit API and don't go back to using EGit. The decorating classes are internals anyway. I will definitely ping you when I have questions. You shouldn't have to use the decorating classes directly, just how they use treewalk's and DirCacheEntry's getRawMode to get the different statuses. We need Git Diff working via REST API, so Libing could start working on the compare editor ASAP. So it seems like addressing Bug 334766 – Add DiffCommand to JGit API is quite important. Otherwise Tomasz' life will be more complicated ;) We had a short discussion with Tomek and having Git commands implemented is only one part of the problem. We also need a way to add Git URIs to GET /file responses. (In reply to comment #2) > For status, it's a tad trickier [...] > > If you need help with this, I'm willing to get my hands dirty. [...] One more question to you Chris, are there any chances that a command for getting status will become part of JGit API? I could file a bug for this, but don't see a point in doing so if you guys do not plan to do it in the nearest future. Or, let me ask it differently, does creating such a command make sense to you? I could try to contribute it to JGit given I will be working on it anyway. Feel free to create a bug for StatusCommand. It would probably return a collection of DirCache's you can iterate over or some type of StatusResult for your convenience. We haven't really debated it since no one has requested it so far. I've just pushed[1] first part of the code which is responsible for the diff operation. Szymon has implemented a special decorator[2] which adds git URIs to JSON object representing a file. Currently only the URI starting with /git/diff/... will produce a meaningful response. Libing could you tell me if the fact that the git status is not there yet is actually blocking you? If this is not crucial I would like to switch to other missing parts of Git REST API[3] like clone. Also, I would then open a separate bug for the status and close this one. [1] b8e4e30e73d4955b51da335b6e8d517736c53a70 [2] org.eclipse.orion.server.git.GitWebResourceDecorator [3] more info: http://wiki.eclipse.org/Orion/How_Tos/Working_with_git Talked to Tomasz today over ST. So he will provide additional REST API to get the file from index. The client side will use the diff and the index as input to generate a mapper. In this way , we can either generate the file in the working tree or get the file content by the file REST APIs. (In reply to comment #9) > So he will provide additional REST API to get the file from index. I filed bug 337463 for that. Leaving this one open until we provide /git/status. We're also going to want REST API for: git add (on a single file, or all currently unstaged files) git reset --mixed (on a single file, or all currently staged files - the inverse of git add) git commit (passing a commit message, and a boolean for "amend" or not) I've asked Libing to create a wiki page with a sketch of the UI we'd like to build. (In reply to comment #11) > git add (on a single file, or all currently unstaged files) bug 338200 > git reset --mixed (...) bug 338202 > git commit (...) bug 338203 > I've asked Libing to create a wiki page with a sketch of the UI we'd like to > build. I think http://wiki.eclipse.org/Orion/How_Tos/Working_with_git is the best place for it... I can see that Libing has already updated it. I've just released[1] a rough version of /git/status which returns status for files that:
* have been added
* are missing -- in index, but not filesystem
* have been modified
* are not tracked yet
Here is an example of JSON respone:
{"Added":[{"Name":"new.txt"}],"Untracked":[],"Missing":[],"Modified":[]}
Libing please let me know what you would like to have next?
[1] ba28ae8967cf4447e64cdbc14f98ec6f60d33480
Pushed rest of the code[1]. The JSON response brings more data now, e.g.:
{"Removed":[],"Added":[],"Untracked":[],"Changed":[],"Missing":[],"Modified":[{"Location":"http://localhost:8080/file/Q/folder/folder.txt","Name":"folder/folder.txt"},{"Location":"http://localhost:8080/file/Q/test.txt","Name":"test.txt"}]}
Files that are added, changed and removed should be recognized as "staged" in the git status UI[2]. While missing, modified and untracked should fall under "unstaged" category.
Libing, if the response in that form doesn't suit you please let me know and open a new bug. I'm closing this one as fixed.
[1] 63a35aa9c83c0aeb75602215b39fc59566d8ddfb
[2] bug 338225
|