How to specify user's fork instead of main repository?

How can Gitpod be configured so that origin remote is not our main repository but the user’s fork. Also, if the user had not already forked our repo, it would be great if Gitpod could do that also. We have a lot of new git/GitHub users, so it would be great if we do some of this behind-the-scenes for the users and allow them to create pull requests without having to create a fork and set up the remote origin on the fork.

[original thread by Deleted]

If you start a repository with the context URL of the main repo, the main repo will be the origin. However, in the staging view, there will be a big warning telling you that you don’thave push rights. There is a button that allows you to fork or switch to an existing fork. you can pick yours and the git remotes will be reconfigured to origin -> your fork and upstream -> main repo. Does that help?

Hi @randell-dawson, great question!

So, generally Gitpod will pick whatever repo URL you give it as origin, so if you provide your users with a link like https://gitpod.io/#https://github.com/<your user>/<the forked repo> they will automatically have the right origin. (Furthermore, in some cases Gitpod will also set an upstream remote to whatever repo the fork is from, e.g. when you open a Pull Request, origin will be the fork, and upstream the base repo).

Another way to do it is to tell your users to open your repository in Gitpod, and then to press F1, and then type the letters fork (this will reveal the GitHub > Fork… command, which allows you to fork the repository to your account).

And yet another way, which is quite new, is to tell users to fork your repository, and then to click on a link like https://gitpod.io/from-referrer/ (e.g. you can put that link in your README.md). This unique URL will automatically detect which repository it was visited from, and open that in Gitpod (using the Referrer HTTP header).

Hope this helps! Please let me know if you have other questions.

Either of the solutions in the last reply above seemed sensible, unfortunately they also cause prebuilds to not be picked up - those seem to only be connected to the main repo.

When you have prebuilds enabled, it looks to me like the best (only?) way to get the main repo named upstream is to call a script in the startup command that explictly calls git remote --add upstream ... (and removes the origin remote, and does whatever else you need).

Hi @rgommers!

Yes, that’s true. While your prebuild configuration files (.gitpod.yml, .gitpod.Dockerfile) may live in both upstream and forks, the prebuild feature itself needs to be enabled explicitly for each repository.

This means every fork needs their owner to enable prebuilds (e.g. by enabling the Gitpod GitHub App for their fork):

Wait, I’m confused. To me these are two entirely seperate things:

  • When you open any repository in Gitpod, whatever repo you’ve used in the context URL is called origin. Also, if your repository happens to be the fork of another repository, that other repository will also get a remote set as upstream (if upstream is not set, that’s a bug in Gitpod’s workspace initialization, unless GitHub also doesn’t know the fork relationship – e.g. the repo was created empty and then received all commits from another repo as push).

  • Gitpod will consider the prebuild configuration in forks as just another set of “stand-alone” configuration files. Thus, if you manually enable prebuilds on the fork, it will start pre-building on every push (regardless of what happens in the upstream repository).

I hope that makes sense. Also, this will become much simpler/clearer once we implement our planned Prebuilds view into the Gitpod dashboard – that way it’ll be immediately obvious which repositories have prebuils enabled or not, where prebuilds are currently running, or whether they’ve succeeded or failed (with a way to consult the build logs).

I’m not looking for separate prebuilds. Nor do I see how this would make sense for most other projects - forks are usually meant to store one’s work in and send PRs back to the main repo, so you want to get the prebuilds of that main repo.

The reason to try the solutions suggested in this thread is to get the main repo always called upstream and the individual’s fork origin. This is the standard convention for our project, documented in contributor guidelines etc. So now if the main repo is called origin, that may lead to (a) some confusion, and (b) people with commit rights accidentally pushing to the main repo rather than their own fork.

For people without commit rights things actually work okay - the IDE shows a “fork” button and then the standard naming gets switched to upstream/origin. I didn’t realize this at first, because I do have commit rights. It would be better if that behavior could be made standard or opt-in via a .gitpod.yml setting rather than via a popup, but it’ll work fine in practice probably.

I think what is missing is to have that behavior (at least a way to opt-in to it), also for people who have commit rights on the main repo.

Thanks, yes I understand how it works right now. I do think my workaround is correct to get the behavior we want.

1 Like

With the recent changes from Theia to VSCode being the default the fork button seems to have disappeared, is there a workaround for this right now?

When you try to push to a repo which you don’t have access VS Code will notify you and suggest to fork.