You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm planning to do a PR for refs and trees (then eventually files). Thought I'd share my plan and get any feedback. Here is the draft interface for trees (refs should be straightforward), the unique bit might be in how the tree structure gets returned. Composing the objects into a tree is an extra step that makes sense to me, but doesn't mirror the API response, so I'm interested to hear your thoughts.
Also, I'm wondering if truncated trees should be treated as an error response, it could certainly just be a property on the Tree object but it feels like its an error to not more explicitly handle it, I could see using a TreeResponse enum with the response case of Truncated that still passes along the tree.
/**
Getting a tree
- parameter owner: The user or organization that owns the repository.
- parameter repository: The name of the repository.
- parameter sha: sha of the commit to get the tree from
- parameter recursively: If true, composes the Tree's subdirectories in the Tree's entries property
- parameter completion: Callback for the outcome of the fetch.
Completion is called with a root Tree object that has an array property entries: [Tree]?
If recursive is true, subdirectories will have further Tree objects in their entries
*/
func tree(owner:String,
repository:String,
sha:String,
recursively:Bool,
completion:(response:Response<Tree>)->Void)
The text was updated successfully, but these errors were encountered:
Nice, a PR is definitely welcome! I would map the error to the GitHub response, since GitHub is returning a 200 when the truncated tree is shown I would also truncate the response. Can you see how high limited is until it is truncated?
I'm planning to do a PR for refs and trees (then eventually files). Thought I'd share my plan and get any feedback. Here is the draft interface for trees (refs should be straightforward), the unique bit might be in how the tree structure gets returned. Composing the objects into a tree is an extra step that makes sense to me, but doesn't mirror the API response, so I'm interested to hear your thoughts.
Also, I'm wondering if truncated trees should be treated as an error response, it could certainly just be a property on the
Tree
object but it feels like its an error to not more explicitly handle it, I could see using aTreeResponse
enum with the response case ofTruncated
that still passes along the tree.The text was updated successfully, but these errors were encountered: