As soon as we heard about the announcement we started looking into what’s required to do the switch, because it would solve a lot of the many small problems that we’re experiencing with the oAuth Application.

We’ve done first successful experiments, but we’ve now hit a blocker that makes our entire use case impossible at this point.
Using the pull request API it is possible to create pull requests with only an existing base branch. Using the content API it is possible to update a file, but it is not possible to push the results to a new branch, only to the source branch.
For our current oAuth Application we’re using the Git Data API to create branches, and then create pull requests from them.
As the entire Git Data API is unavailable to GitHub Integrations it’s now impossible to change the content of a file and go through a pull request first.

I don’t think that this is a reasonable limitation, because changing the content on the default branch directly is a dangerous and unwanted thing to do, not only for bots, but also for humans. Thanks to required status checks it wouldn’t work most of the time anyway. This means the API currently supports a commonly discouraged workflow, while blocking the recommended way of going through pull requests and reviews.

An ideal solution would be to add a feature to the Content API to update a file, but push the results to a different branch. For now it would be really amazing if you could just allow the Git Data API for integrations, so we can at least use our current solution.

It would be really great to hear your thoughts on this and, if at all possible, a rough time frame on when or if changes like these could go live. I know that it’s not an easy thing to publicly communicate a timeframe, but having a rough idea would really help us decide on how to move forward here.
Integrations are really a great way to make our service work with GitHub – almost like most of the features are directly from our wishlist – but as a small company that has to focus and prioritize it would be of utmost value to know if it’s worth spending our time on Integrations now, or on the existing application – knowing that we can help improve our users experience immediately, while having to rewrite stuff for Integrations in the midterm to longterm future.

We figured we’ll be using our read/write access on the git repository in the meantime. Permission wise everything the Git Data API would allow us to do is already available to us via cloning and executing git commands – just that that’s a lot of overhead.

We can’t wait to throw that code away again, and go back to the Git Data API