Bugzilla – Full Text Bug Listing
| Summary: | Provide REST API for git command line | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Tomasz Zarna <tomasz.zarna> | ||||||||
| Component: | Git | Assignee: | Project Inbox <orion.git-inbox> | ||||||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | kdevolder, ken_walker, lidortal, Szymon.Brandys | ||||||||
| Version: | 0.4 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | 373789 | ||||||||||
| Bug Blocks: | 369608 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Tomasz Zarna
It may be more convenient to have the arguments to the git command passed as an array of Strings. I.e. in the same way that a Java main method would receive them.
Both a version with a 'one long String' and an array of Strings are likely useful. But for the use case I have in mind with the gcli client it would be more convenient to have the args passed as an array. This will avoid issues around escaping quotes etc.
If passed as one long String instead. I can work with that as well, but the rules for quoting and escaping characters like quotes and spaces to avoid splitting the arguments incorrectly will have to be very clearly spelled out.
For the example below. If passed as an array of Strings we don't need to worry about quotes and parsing them. The array passed will look like this
args = new String[] {
"commit",
"-m",
"the fix"
}
I.e. the assumption is that handling quotes is done by whatever tool is used to split arguments on the commandline and it doesn't need to be handled by the server-side git api implementation.
A one long string version would be more convenient for a 'dumber' client that simply provides a line for the user to enter text and sends the text as is to the server.
(In reply to comment #1) > It may be more convenient to have the arguments to the git command passed as an > array of Strings. Fine with me. Another question: what kind of response would you expect to get from the server if you requested a long running command? The Orion API, including Git API, returns 202 (accepted) in that case. The response also contains a location of the created task. You an periodically check the location to see whether the task/command is still running or has completed That's a good question. I haven't put too much thought into proper handling of long running operations. But I do recognize it is important for long running operations. Especially when the operation is just a thin wrapper around atraditional shell-like command, it is important for it to be able to return and display the output incrementally. Currently I'm getting the results of external commands with an xhr request that returns the whole result at once. This is no good. It is rather disturbing for long running commands. If you already have an established way of handling cases like these... I don't see much reason to deviate from it. Just one question, would the mechanism you have in mind allow for commands that return a text stream to render the text 'incrementally' in the client side UI? Kris Done a bit of googling about 'Streaming' data into a browser. Seems like older browser don't have good mechanisms available. But HTML5 includes 'WebSockets'. So I wonder if using HTML5 WebSockets for commands that want to 'Stream back' textual command output as it becomes available would be a good solution here. Still trying to wrap my mind around exactly how that would work. Also I'm really not sure about what that means for browser compatibility. But it seems like it would be the best mechanism if it is available. If not using WebSockets... I could also imagine a mechanism where you get a response back that blocks (for a limited amount of time) and returns as soon as it has some interesting chunk of data available. Plus it also provides a new URL where to retrieve the next bit of data. I believe this technique is called 'long polling'. I.e. it is like polling, but with connection being kept open on the server side until it has something interesting to send (Or a timeout is reached). The client always tries to keep connection open if it is closed so the server has a way to 'push' data. Here is a link with a nice overview (includes some info on WebSockets and the polling type stuff it is supposed to replace): http://websocket.org/quantum.html Kris (In reply to comment #3) > Just one question, would the mechanism you have in mind allow for commands that > return a text stream to render the text 'incrementally' in the client side UI? I don't think that's necessary. Most git commands print to std out when done, even when this kind of "streaming" would make sense: eg. display commits while iterating over a log. For the rest, this kind of approach is used for progress reporting: eg. when clonning you can see how many objects have been fetched so far even though the command haven't finished yet. The latter can be imitated by the task info (see comment 2) available while the command is still running. Since requests from GCLI would create new tasks, to be RESTful, they should be POSTs rather than GETs. That's not a big deal, isn't it? > Since requests from GCLI would create new tasks, to be RESTful, they
> should be POSTs rather than GETs. That's not a big deal, isn't it?
I don't expect that it should be a big deal. From the point of view of the client, I suspect the only difference is we need to use dojo.xhrPost method instead of dojo.xhrGet.
Kris
Tomasz... In light of discussion on orion call this morning... Should we reconsider the 'send array of Strings' approach? With gcli on the client side each command, command option and command parameter does have to be implemented/declared individually already. The main reason why I suggested the 'send array of String' approach is that it seemed like the quickest way to get something going on the server. Another approach could be that we start by providing a 'text output' option for existing rest API and I try to wrap those into gcli commands. Then we add commands one by one on demand. As an experiment we could start with 'git status'. Anyhow, I don't want to argue for either a 'array of strings' or 'individual commands' approach at this time. Just want to make it clear I'll go along with whatever is chosen to be the 'right way'. In some sense the one-command at a time REST api implementation is probably easier for me. So I certainly don't want to argue against it :-). But I realize it is probably more work for you (so I think it should be your call if you can/want to invest the required time into this). Kris The "send array String' approach is fine with me as long as we use it to quickly deliver a missing bit of the Orion git support (REST API + UI). So, if a command can be executed with an existing REST API I would use that API. This how the git support should evolve IMO: 1. For a missing git command define a GCLI command. Execute it via the pseudo-REST API (sending args as Strings), expect plain text response. The same applies if the proper REST API exists but it doesn't support a specific option e.g. there is an API for merging but you cannot use it to squash commits for the time being. 2. Make the pseudo-REST API return JSON response, just like the proper API would do. The JSON data will probably contain more info than the text response from 1. 3. Implement the missing bit as a proper REST API, return the same response as in 2. 4. If/once the API is in place call it from the GCLI. That would require you to map GCLI commands to appropriate HTTP methods, URIs and params as described here: http://wiki.eclipse.org/Orion/Server_API/Git_API. When done, deprecate the API used in 1. 5. Provide UI for the new REST API. Optionally, remove the command from GCLI. Returning plain text from the current REST API is an option, but I don't think it's worth the effort. Translating JSON to a meaningful text response shouldn't be that hard. Note that in 1. you are able to call only commands listed here: http://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit.pgm/META-INF/services/org.eclipse.jgit.pgm.TextBuiltin, moreover they may support only a subset of options/args you would expect. Bug 365439 in JGit is for changing this situation. Feel free to add a comment there mentioning a command which cannot be executed in JGit's command line. Another obstacle is bug 373789 which is about adding JGit's Command Line to their update site. AFAIK the only way to work with it right now is to download the source. I've already found some minor issues with the current shape of the o.e.jgit.pgm project like https://git.eclipse.org/r/#/c/5290/, I expect more coming. Created attachment 212379 [details]
Orion/Server patch v01
Created attachment 212380 [details]
mylyn/context/zip
Created attachment 212382 [details] JGit patch v01 Quick and dirty patch for JGit required by the Server patch. Kris please apply both of them and let me know if it works for you. Have a look at tests to figure out how to construct the request. You will get plain text response. So, this is like point 1 from comment 8 for all commands supported by JGit CLI. It took me quite a bit of effort to get all the dependencies together.
(I was previously just using RC4 as target platform.)
It feels like I'm almost there now, everything compiling except for the new git code you added to server. Mostly because accessing non-exported JGit stuff it seems. I gather that is the purpose of the JGit patch?
Unfortunately the JGit patch doesn't apply:
> git apply jgit_v01.patch
fatal: corrupt patch at line 171
So I'll try to proceed by simply making the protected/public/export changes to JGit myself.
Kris
(In reply to comment #12) > Unfortunately the JGit patch doesn't apply: > > > git apply jgit_v01.patch > fatal: corrupt patch at line 171 Try applying the patch in Eclipse. It works just fine for me. If have just pulled JGit's master, you can ignore the nonmatching change in o.e.jgit.pgm/META-INF/MANIFEST.MF. That part of the patch is already in master: https://git.eclipse.org/r/#/c/5290/ Kris any news here? Can I be of any help? I haven't worked on the GCLI stuff in a while. I'm really waiting for the Gcli CQ to go through. There is plenty of other things (non-orion) to keep me busy in the mean time :-) No worries, just let me know when you ready to work on this again. I will update both patches then. For the time being I'm changing the target milestone to .5. (In reply to comment #15) > I haven't worked on the GCLI stuff in a while. I'm really waiting for the Gcli > CQ to go through. There is plenty of other things (non-orion) to keep me busy > in the mean time :-) Hi Kris, do you think this is still in the plan for .5? Tomek may discontinue working on that soon and someone will take over this work after .5. Hi Szsymon, I can't promise that I'll be able to work on this in 0.5 timeframe. Of course I won't be offended if that means you would like someone else to take over the work instead. Kris It seems to be out of the 1.0 plan I can place it in the platform section however we need to find a resource to be able to work on it. Does Orion supports REST API for git command line? If yes from which version? The last change in this discussion was quite long ago… Thanks, No, we never went this direction. Our Git UI has evolved quite a lot over the years, and we don't find command line access important. It could eventually be exposed via docker container shell in the future rather than via a custom REST API. |