Permalink
Browse files

Announce plans to fix `type` value for submodules

Prior to 2013-04-30, you could not GET a submodule via the Repository
Contents API. (You could see the submodule listed when you GET the
directory that the submodule resides it, but you could not GET just the
submodule.) On 2013-04-30, we added the ability to GET a submodule.
(See 81c7e58.) When you GET a submodule, the "type" is returned as
"submodule".

Prior to 2013-04-30, when you listed the contents of a directory using
the Repository Contents API, the output included submodules, but it
returned the "type" as "file". The type *should* be "submodule". We are
leaving this behavior as is for v3, so as not to break any client code
that might depend on this behavior. In the next major version of the
API, the type will be returned as "submodule".
1 parent 81c7e58 commit 1b329b04cece9f3087faa7b1e0382317a9b93490 @jasonrudolph jasonrudolph committed Apr 30, 2013
Showing with 1 addition and 0 deletions.
  1. +1 −0 content/index.md
View
@@ -46,6 +46,7 @@ objects.
* `[ ]` Use JSON to POST to the "repos/:owner/:repo/forks" endpoint, instead of a query string.
* `[✓]` <del>User Emails come back [as a hash][v3-email] instead of a string.</del>
* `[ ]` Remove the unused "bio" field for Users.
+* `[ ]` When listing the contents of a directory in the [Repository Contents API](/v3/repos/contents/#get-contents), fix the `type` value returned for submodules: change the value to `"submodule"` (instead of `"file"`).
### Breaking Beta Changes

1 comment on commit 1b329b0

Please sign in to comment.