gitpod
gitpod copied to clipboard
Allow maintainers with write access to an org repo to push changes to a contributor's branch directly
Is your feature request related to a problem? Please describe
Many open-source projects have adopted the following workflow for making contributions:
- a central repository, usually under a GitHub organization
- contributors fork the central repository
- they make changes in their fork
- then they submit a PR to the main repository
Which can also be illustrated as follows:

Some of these contributors can be maintainers with write access to the central repo, some are casual contributors without such rights. These maintainers can usually push directly to the branch of the contributor repo, for example to make minor changes to a PR.

However Gitpod does not seem to be allowing this at the moment.
Describe the behaviour you'd like
Just like the GitHub UI allows maintainer for pushing to the branch of the contributor:

It should also be possible to push to the branch of the contributor from a Gitpod instance from the command line with git push origin branch-name.
Here is a video summarizing the desired workflow. Attempting to do this on Gitpod gives a 403:
https://user-images.githubusercontent.com/591645/209089968-ea5fe7d8-d6f0-4026-8d67-21e0bab66127.mp4
Whereas it is possible to do this via the GitHub UI:
https://user-images.githubusercontent.com/591645/209090099-d5967675-1ea3-4d6c-982a-32a141411af3.mp4
Describe alternatives you've considered
I have been using the following workarounds for now:
- start Gitpod from a PR, make a small change, then copy the change from the Gitpod instance (for example a formatting / prettier pass). Then use the GitHub UI to edit the contributor's branch directly and paste the change.
- same as above, but open a PR targeting the fork of the contributor instead of pushing to the branch directly.
- clone the repo locally without using Gitpod. Make a change, commit and push to the contributor's branch directly. GitHub allows this from the CLI over SSH (and HTTPS?).
- open a new PR while keeping the commits from the original branch, just to be able to push new changes on top of it
Each of these have drawbacks:
- This is tedious, and doesn't scale if the change to apply is large
- This adds an additional round-trip and the other contributor first has to merge the PR. Sometimes they might not be notified about the PR on their fork unless they are pinged explicitly.
- This is a manual workflow that doesn't use Gitpod, which is long and tedious
- This breaks the normal flow of keeping the commits and the existing conversation in one place (previous comments and reviews are not moved to the new PR)
Additional context
This was also briefly discussed on Twitter a couple of months ago: https://twitter.com/jtpio/status/1555533757695856640
Thanks for the help!
Just tried another scenario to double check the behavior, and it seems like there are also permission issues when trying to push to an org repo directly, even with full (admin) access to the repo.
Here a list of steps using https://github.com/jupyterlab/jupyterlab as an example (an organization repo on which I have admin access):
- Open Gitpod from https://github.com/jupyterlab/jupyterlab
- Wait for VS Code to load
- Create a new branch
- Make a change, then commit
- Try to push the change with
git push origin my-branch
Trying to publish the branch on the origin (org repo) directly results in the following "Permission denied" error:
https://user-images.githubusercontent.com/591645/211581461-632d8a11-0b35-4bc8-9b42-b7d1f017face.mp4
However adding a new remote pointing to my fork and pushing to it works fine:
https://user-images.githubusercontent.com/591645/211581697-c497eaa1-6f3a-4191-818e-f237d6181b36.mp4
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
It would be nice to keep the issue open a bit longer as having support for this workflow would be super helpful to maintainers!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Commenting here after the stale bot :)
Still thinking it would be a great feature!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Commenting again here as this would still be useful!
We are not doing something special here, we just use the git token that we got from your OAuth. It could be that the JupyterLab org doesn't have granted access for Gitpod OAuth. Could you check this link and see what it says next to the jupyter org? You might request access, there.
Oh that would explain why. I just granted access for another org, opened a PR created from the fork of a contributor, made some changes and pushed to the fork successfully.
After pushing the changes to the branch, the following notification showed up. Not sure it's relevant though since the changes were pushed successfully?
Thanks @svenefftinge!
This can likely be closed then. Or this page in the docs could have a small mention of this use case too: https://www.gitpod.io/docs/configure/authentication/github#errors-with-private-repositories-on-github-orgs