How to set default fork for pull requests?

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?

  • GIT diff says OLD mode is 100644 and new mode is 100755, but nops
  • Gitignore - Ignore only images & ignore everything except .. in single command
  • Retrieve missing files from remote repo?
  • How to update a file in remote repo, without cloning that repo first?
  • Change connected commit on release github
  • “Hg to Hg (Gateway) to SVN” compared to “Git to Git (Gateway) to SVN”
  • Android Studio Backup Source to Repository
  • git clone issues via an SSH proxied host
  • How to make an alias for git subtree push command with repository and refspec
  • After fixing conflicts git still complains?
  • “Bad configuration option” on linux terminal, during bitbucket ssh connection.
  • Error in Visual Studio while trying to clone a git repository
  • 2 Solutions collect form web for “How to set default fork for pull requests?”

    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.

    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.

    Git Baby is a git and github fan, let's start git clone.