How to set default fork for pull requests?

Question

I have a set of documentation for my company's API, based on the excellent Slate framework from TripIt. Per instructions, I forked their repo and proceeded to customize it. That fork lives here.

The obnoxious thing is that when contributors in my organization do a new pull request, the "base fork" on the Github "Comparing Changes" screen defaults to TripIt's repository, not my fork. They've more than once sent pull requests to the wrong place. Telling people "don't do that" isn't a particularly reliable solution. How can I set the default for where PRs are based to my fork?

Participial

Do you need to keep the link to upstream (=TripIt's base fork)? Because as I understand it, you use the TripIt repo to document your own company's code. Right? You are not company-wide contributing to Upstream? If you only need the repo for your own company's documentation, you can just clone the repo, and not fork it. If you clone it, there is no link left to upstream, and all PR's are pointed at your origin. And then origin is the default for your PR's, exactly as you want it. – Secretarygeneral

Answer 1

GitHub keeps track of forks made through their interface and assumes pull requests will be for that original repository. You need to tell GitHub that your copy is not a fork but rather a regular repository that just happens to have identical history. Sadly, GitHub doesn't offer a good way to just uncheck the fork link. I typically solve it this way:

1. Clone the repository, git pull, and ensure your local copy is completely up to date.

2. Delete the repository on GitHub.

3. Create the repository on GitHub using the exact same name. Ensure it's an empty repository (don't create a README or LICENSE file.)

4. git push all the content back into the repository. (You may need to switch to each branch and push it, and you also may need to git push --tags.)

FRAGILE: This approach will lose existing GitHub issues and pull request comments. If you're using these heavily, this approach is probably a bad idea, and you should contact GitHub customer support to help you instead.

Sequacious

I'm all for DIY, but github support is very good at taking care of this and would be my first choice here. – Coly

@Sequacious how would you then merge changes from the original slate repo? (say if there is a new release) – Bufordbug

@TomFox: I usually add two remotes to my local clone. git add remote origin https://my.github.repo/... and git add remote upstream https://their.github.repo/.... That way when I want to update from their system, I git pull upstream master and git push origin master to get their changes into my fork. – Sequacious

Answer 2

It is unfortunate that GitHub does not provide a way to configure the default PR target repo.

If you can delete (or get the owner to delete) the original repo A from which B was forked, then that will do the trick.

If it is not possible/agreeable to delete A, but the owner of A is willing to do the following, then the fork link gets broken, on GitHub Enterprise at least:

• mark repo A as Private
• mark repo A as Public again

After doing this, repo B (which was originally forked from A) will default to opening PRs against itself, rather than A.

Note: if A itself was forked from something further back in the history, then unfortunately it seems that B starts defaulting to opening PRs against that repo once A has gone. The only solution would be to apply the above to all repos upstream in the fork tree :(

Wayless

Answer 3

Your other developers seem to have forked TripIt's repository, so that is the source/parent of their work. In fact, if you open your own repository, you will see it hasn't been forked at all (the fork count is 0).

When they issue a merge request, by default github shows that repository as source, and so the pull request isn't sent to you.

The simplest workaround in this case is to ask your dev's to fork your repository, and work on it.

Organism

Actually, I've already followed the approach suggested above, so you're seeing the repo after it was fixed. Thanks though :) – Participial

Answer 4

GitHub has a virtual agent that automatically submits a ticket for detaching a fork. This was much easier for me to do than deleting and re-creating the repo. Only took a couple of hours for them to do it.

https://support.github.com/request?q=Detach+fork+from+repo

Sasin

Answer 5

Yes, it's a bad situation...

The only solution I know of (other than deleting the fork and recreating/pushing directly from a local clone as described here ) is to have the upstream owner make the original repo PRIVATE and then return it to PUBLIC. Taking it private breaks the link to forks permanently.

But of course that requires action by the upstream owner. Github should really solve this, but it's been an issue for a very long time.

Compotation