How can I fork the original repo when I've already forked a different fork

I've previously forked jockm/vert.x and sent him a pull request. Now I want to fork vert-x/vert.x (the upstream of jockm/vert.x) and send them a different pull request. But when I click the Fork button, unsuprisingly I end up in my tjcrowder/vert.x fork of jockm/vert.x instead. Is it possible to fork both vert-x/vert.x and jockm/vert.x simultaneously such that I can send each pull requests as appropriate?

I fear the answer may be the same as for this question about the converse situation ("there's no GitHub way, but you can add a remote repo") but I'm hoping otherwise — not least because I don't see how the answer there would allow me to send pull requests to the new remote.

34842 次浏览

I didn't see any specifics on "multiple forks", so I would probably end up creating another GitHub account, under which I would do the second clone, and send the different pull request to vert.x/vert.x.

Since you can have "Multiple github accounts on the same computer" (with the right ssh config file, also described here), it is a possible workaround.


Note that, however, this is supported by GitLab, with GitLab 14.0 (June 2021):

Edit default path and project name when forking

Edit default path and project name when forking

Forking a project enables you to have an exact copy of an original repository where you can experiment, apply changes, and submit contributions to the parent project.
Your forks should have meaningful names that explain their goals, and if your project is diverging, you may need multiple forks of a single project.

In this release, GitLab now supports editing the project name and project slug directly when you create a fork.

You can now create multiple forks of the same project, each with a different name, all in the same group!

https://about.gitlab.com/images/14_0/edit_default_path_and_project_name_when_forking.png -- Edit default path and project name when forking

See Documentation and Issue.

There's no GitHub way (small lie, see below), but there's also nothing to fear.

By definition, your fork of a fork is a fork of the original. When you open a pull request, you get the option to choose both the origin and the destination for your pull request. The choices available there obviously depend on the fork graph, but as long as there is a path in the graph between the 2 repositories, you should be safe. Also, since pull requests live on the website side, you don't even need to add a remote as long as you don't want to use it from git.

Now of course, you might want to reconsider your place in that graph, and make yourself a direct child of the real upstream, but that's mostly unrelated.

As said earlier there is actually a twisted way to have multiple forks, which is to create organizations and fork in them. That way you can "own" multiple repositories in the same graph. But there's really no need to go there.

It seems like the better option would be to create a branch on your fork, and create a pull request from that branch. You can use branches to "fork" your version

Thanks to sigma's answer, I saw that not only is the upstream repo available when I go to do a pull request on the jockm/vert.x repo, but all other forks of the upstream repo are as well. So what I ended up doing was:

  1. Deleting my fork of jockm/vert.x and instead forking vert-x/vert.x, since mostly I want to work within the main upstream repo, not jockm's version.
  2. Creating a branch for the commit I wanted to send to jockm, and a separate branch for the commit I wanted to send to vert-x.
  3. Making the relevant changes to each branch.
  4. Sending pull requests for each branch to the relevant repos, since the jockm/vert.x repo is listed as a possible target for the request (along with about 200 other forks).

I used separate branches (basically topic branches) so that those commits would remain the only thing in those pull requests, since subsequent commits on the same branch are automatically added to the pull request, and these changes needed to remain isolated until/unless merged.

You could also just create a new Organization under your profile/settings. Then you can fork different states of the same original repo through the same account.