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
So file-commit has two required properties content and commit, with the first being nullable.
It's my understanding that content is null in the case of DELETE, in the case of PUT it's present and contains the information of the just-created file.
However I don't understand in what case all the properties of a non-null content or a commit would be missing, surely most or all properties should be required, with the possible (probable?) exception of commit.verification?
All in all, file-commit.content looks like a slightly cut down version of content-file (without encoding and content), so probably should otherwise have the same schema? And for both it seems like the type field should be an enum with file as the only option?
I think file-commit.content could be something like a file type with content-file being an allOf(file, {encoding: ..., content: ...}) but I guess that increases the complexity of the schema and currently there's a single use site for allOf so that's probably a tad too much.
The text was updated successfully, but these errors were encountered:
Having taken one more look at this type, it also seems very much like the commit object is a straight git-commit, the properties are exactly the same, with "author" and "committer" being git data (triplet of name, email, and date) rather than github objects (simple-user).
The only difference is that all properties of file-commit.commit are currently non-required, but for both create/update and delete all the properties seem to be filled, so I think this is just the schema being under-specified and it should just be:
@xmo-odoo - Thank you for opening the issue. We've chosen to keep the file-commit.commit object and the git-commit object distinct for now in the schema although as you've pointed out they are in fact the same under-the-hood.
The "updating "contents" endpoints (
PUT
, orDELETE
on/repos/{owner}/{repo}/contents/{path}
, but notGET
) all respond with afile-commit
defined thus:So
file-commit
has two required propertiescontent
andcommit
, with the first being nullable.It's my understanding that
content
isnull
in the case ofDELETE
, in the case ofPUT
it's present and contains the information of the just-created file.However I don't understand in what case all the properties of a non-null content or a commit would be missing, surely most or all properties should be
required
, with the possible (probable?) exception ofcommit.verification
?All in all,
file-commit.content
looks like a slightly cut down version ofcontent-file
(withoutencoding
andcontent
), so probably should otherwise have the same schema? And for both it seems like thetype
field should be an enum withfile
as the only option?I think
file-commit.content
could be something like afile
type withcontent-file
being anallOf(file, {encoding: ..., content: ...})
but I guess that increases the complexity of the schema and currently there's a single use site for allOf so that's probably a tad too much.The text was updated successfully, but these errors were encountered: