-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tree and Refs API Calls #40
Labels
Comments
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? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: