Community
Participate
Working Groups
I am using the new diffURI , I hit a problem by doing : 1.Add a new file (new2.js) 2.go to git status , and click on the new2.js I got error "Unable to load http://localhost:8080/git/index/file/T/new2.js status:500" http://localhost:8080/git/diff/Default/file/T/new2.js?parts=diff gives me the following response , which is correct diff --git a/new2.js b/new2.js new file mode 100644 index 0000000..aa515f6 --- /dev/null +++ b/new2.js @@ -0,0 +1,18 @@ +asdfasdf +asdf +fas +df +asd +fa +asd +f +asd + +var asdf = " asdfasfasdfasdf"; +as + +sd +fasd +f +asd +fasd \ No newline at end of file http://localhost:8080/git/diff/Default/file/T/new2.js?parts=uris gives me the following response , which is tricky {"Git":{"New":"http://localhost:8080/file/T/new2.js","Old":"http://localhost:8080/git/index/file/T/new2.js","DiffLocation":"http://localhost:8080/git/diff/Default/file/T/new2.js"}} I am using response.Git.Old to get the file content on the right hand side , but apparently "/git/index/file/T/new2.js" does not exist yet.
Would 404 (Not Found) be a better response to GET on "/git/index/file/T/new2.js"? I could add an explanation saying that the file has not been added has not been added to the index yet. This kind of message could be used to distinguish between 404s like this and others when the file is simply unknown (e.g. "not-there.js", which is nowhere to be found: working tree, index, local/remote repository). How does it sound?
(In reply to comment #1) > Would 404 (Not Found) be a better response to GET on > "/git/index/file/T/new2.js"? I could add an explanation saying that the file > has not been added has not been added to the index yet. This kind of message > could be used to distinguish between 404s like this and others when the file is > simply unknown (e.g. "not-there.js", which is nowhere to be found: working > tree, index, local/remote repository). How does it sound? The perfect solution would be preventing me even from calling the GET request on a not-there file. Is it possible to add another flag for the file URIs you return to me ? If it is breaking the general rules , using 404 is another solution but we will see errors in debug mode , which is not ideal.
(In reply to comment #2) > Is it possible to add another flag for the file URIs you return to me ? What kind of flag do you have in mind? What would you expect in a situation when you have deleted a file in your working tree, but it's still in the index? Opening the side-by-side compare from Git Status page for that file results in the left side being empty (the file does not exits) and the right side showing the content stored in index. How do you handle this case? What if you would like to be able to copy some content from right to left, or just edit the file? What URI would you use to save it? In this case an empty URI is not an option. Moreover, a URI that returns 404 is perfectly valid. It returns: { httpCode: 404, message: "File not found: /O/deleteme.txt", severity: "error", code: 0 }. For the case from comment 0 the response could look like this: { httpCode: 404, message: "File not in index: /T/new2.js", severity: "error", code: 0 }.
(In reply to comment #3) > What kind of flag do you have in mind? A boolean , indicating the fileURI exists or not. It is important to have a such flag on the Git.Old because I am always trying to GET content from Git.Old. > > What would you expect in a situation when you have deleted a file in your > working tree, but it's still in the index? Opening the side-by-side compare > from Git Status page for that file results in the left side being empty (the > file does not exits) and the right side showing the content stored in index. > How do you handle this case? I am not trying to get the Git.New content so the left side content is generated by the Git.Old + diff. > content from right to left, or just edit the file? What URI would you use to > save it? In this case an empty URI is not an option. I think for a delete file , we will not allow edit on the left side. The compare editor just serves like a indicator. >Moreover, a URI that > returns 404 is perfectly valid. It returns: { httpCode: 404, message: "File not > found: /O/deleteme.txt", severity: "error", code: 0 }. For the case from > comment 0 the response could look like this: { httpCode: 404, message: "File > not in index: /T/new2.js", severity: "error", code: 0 }. I am not saying this is not a solution but does it worth to give it a try to GET a none-exist-file ?
(In reply to comment #4) > I am not trying to get the Git.New content so the left side content is generated > by the Git.Old + diff. This is how your Compare editor works, but I can imagine another implementation which only needs left and right side (Git.Old and Git.New) and generates the diff on the fly. The server API shouldn't be tailored to a specific client. In this particular case, by not doing so we even make the response simpler. > I think for a delete file , we will not allow edit on the left side. The compare > editor just serves like a indicator. Why not? This seems to a valid scenario when you want to restore some parts of the deleted file. > I am not saying this is not a solution but does it worth to give it a try to > GET a none-exist-file ? Well, you as a client don't know that a priori. You should make no assumption whether the URI points to an existing resource. Note that in a multi-user environment this might have changed in the meantime (e.g. someone has deleted or added the file, even you working ion a separate browser tab).
Anything is better than 500, so I've released a fix[1] which returns 404 in that case. [1] http://git.eclipse.org/c/e4/org.eclipse.orion.server.git/commit/?id=15ae9367b4baf8a43e65bc153d9a8fa07627dd0f
(In reply to comment #6) > Anything is better than 500, so I've released a fix[1] which returns 404 in > that case. > > [1] > http://git.eclipse.org/c/e4/org.eclipse.orion.server.git/commit/?id=15ae9367b4baf8a43e65bc153d9a8fa07627dd0f Ok , I will handle 404 as an exception .
