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

Bug 345402

Summary:	[server] Review the Git JSON representations
Product:	[ECD] Orion	Reporter:	Szymon Brandys <Szymon.Brandys>
Component:	Git	Assignee:	Project Inbox <orion.git-inbox>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	normal
Priority:	P3	CC:	tomasz.zarna
Version:	0.2
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:
Bug Depends on:	343367
Bug Blocks:

Description Szymon Brandys

2011-05-11 07:30:55 EDT

We need to discuss our current JSON representations in Git API. These are issues that I see now, but there may be more:

1. There are locations in JSONs and there is no way to get a full result with one call in some cases, for instance:

In the Git node in File JSON, there is RemoteLocation. To get commits on a branch, I need to do the following:
- call GET on RemoteLocation it returns the list of remotes
- call GET on the remote to get the list of branches
- call GET on the branch location to get the branch details

We should have a way to get branch details with one call here. For instance in Files API we also have ChildrenLocation, but depending on 'depth' param, we can get collections of children to the given depth.

2. We need to have parents locations in JSONs, for instance each branch object should have a reference to its remote or/and repo.

3. I'm not convinced about how we use the Children key in our representations. I think it is probably ok to return the list of commits under Children for GET /git/commit. However it is unclear that tags are under Children in a commit representation.

Comment 1 Tomasz Zarna

2011-05-11 08:57:23 EDT

I agree, we have this one blocked by bug 343367, so we can get a bird's eye view on the problem first. Once we update the doc and see where the response representation could be adjusted we will switch to this bug... and when done, update the doc again.

Comment 2 Szymon Brandys

2011-05-20 09:28:53 EDT

We need a Type field for each Git JSON representation. 

For instance when I use GET http://localhost:8080/git/remote/file/g/ to get the list of remotes, I get:
{"Children": [{
  "Location": "http://localhost:8080/git/remote/origin/file/g/",
  "Name": "origin"
}]}

When
{
  "Location": "http://localhost:8080/git/remote/origin/file/g/",
  "Name": "origin"
}
is passed further to some UI widget, there is no way to detect that it is a git remote representation, unless we parse the URI.

Comment 3 Tomasz Zarna

2011-05-20 09:37:33 EDT

We also agreed to include CloneLocation for all types of Git resource objects.

Comment 4 Szymon Brandys

2011-06-06 10:14:55 EDT

We did some of the work during M8. Further review is planned post 0.2.

Comment 5 Tomasz Zarna

2011-08-18 09:55:54 EDT

All these issues have been fixed with bug 349658:

Ad1. If you refer to a remote branch this can be done now with 2 GETs, one for RemoteLocation, second for Children[i].CommitLocation from the response on the former.

Ad2. This is also done in most cases, CloneLocation is in sight of each response.

Ad 3. Tags for a commit are listed node named "Tags", not "Children"

*** This bug has been marked as a duplicate of bug 349658 ***