How to pull request a wiki page on GitHub?

You can't do a pull request, but you can open an issue, paste a link to your wiki page, and let them merge in your wiki page to their wiki page.

In short:

They just need to clone your wiki page repo, (git clone YOUR_FORKED_REPO.wiki.git), squash all of your wiki commits into one big commit, then cherry-pick this big squashed commit onto their repo. That will bring in all of your wiki changes into their wiki.

Full instructions:

(COPIED FROM Larry Botha's github gist HERE: https://gist.github.com/larrybotha/10650410):

Merge Wiki Changes From A Forked Github Repo

This is inspired (or basically copied) from How To Merge Github Wiki Changes From One Repository To Another, by Roman Ivanov, and serves to ensure that should something happen to the original article, the information remains nice and safe here.

Terminology

OREPO: original repo - the repo created or maintained by the owner

FREPO: the forked repo that presumably has updates to its wiki, not yet on the OREPO

Contributing

Should you want to contribute to the wiki of a repo you have forked, do the following:

  • fork the repo
  • clone only the wiki to your machine: $ g clone [FREPO].wiki.git
  • make changes to your local forked wiki repo
  • push your changes to GitHub

Once you are ready to let the author know you have changes, do the following:

  • open an issue on OREPO
  • provide a direct link to your wiki's git repo for ease of merging: i.e. [FREPO].wiki.git

Merging Changes

As the owner of OREPO, you have now received a message that there are updates to your wiki on someone else's FREPO.

If wiki changes are forked from latest OREPO wiki, you may do the following:

$ git clone [OREPO].wiki.git
$ cd [OREPO].wiki.git

# squashing all FREPO changes
$ git pull [FREPO].wiki.git master

$ git push origin master

If OREPO wiki is ahead of where FREPO forked from, do the following:

$ git clone [OREPO].wiki.git
$ cd [OREPO].wiki.git
$ git fetch [FREPO] master:[FREPO-branch]
$ git checkout [FREPO-branch]

#checkout to last OREPO commit
$ git reset --hard [last-OREPO-commit-hash]

# do massive squash of all FREPO changes
$ git merge --squash HEAD@{1}
$ git commit -m "Wiki update from FREPO - [description]"
$ git checkout master

# cherry-pick newly squashed commit
$ git cherry-pick [OREPO-newly-squashed-commit]
$ git push

I've taken a different approach to this, which is to push exactly the same content into both the main repo and the wiki. This won't be to everyone's tastes, but Risk-First is mainly a wiki with a few Jekyll pages in the main repo.

This means the pull request/fork process works fine. However, after merging a pull-request I have to do the extra step of pulling to my local repo and then pushing to both the main repo and the wiki, which git supports fine with multiple origin URLS:

localhost:website robmoffat$ git remote show origin
* remote origin
  Fetch URL: [email protected]:risk-first/website.git
  Push  URL: [email protected]:risk-first/website.wiki.git
  Push  URL: [email protected]:risk-first/website.git
  HEAD branch: master

In order to achieve this, I merged the commits from both repos following this:

How do you merge two Git repositories?

And then push to both repos like this:

Git - Pushing code to two remotes

Hope this helps someone.


We have found the best solution for the problem so far in https://devonfw.com :

  1. Put your documentation into the git repository together with the code inside a documentation folder.
  2. Extend your travis-ci build with some magic that stages all changes from that documentation folder with transformations applied to the wiki git. See last example link below.
  3. Consider the wiki as read-only view on the documentation. Please note that with github.com you can still view and directly edit the files in the documentation folder. So you still can fix typos within the browser within seconds (even as PR without permissions on the repo) - just not via the wiki.
  4. When a contributor forks, he also has the documentation with the code. He can change both in one PR and all gets reviewed in the same process so after merge Code and Doc remains in sync. Still you have the nicer UX for reading documentation in the wiki with sidebar, etc.

As we are 100% OSS we love to share our hard efforts to come to this great solution. Here are the links as example:

  • https://devonfw.com/website/pages/docs/master-devon4j.asciidoc_introduction.html
  • https://github.com/devonfw/devon4j/wiki/architecture
  • https://github.com/devonfw/devon4j/blob/develop/documentation/architecture.asciidoc#architecture
  • https://repo1.maven.org/maven2/com/devonfw/java/doc/devon4j-doc/3.2.0/devon4j-doc-3.2.0.pdf
  • https://github.com/devonfw/devon4j/blob/develop/.travis.yml

GitHub doesn't support pull requests for the wiki repository, only the main repository (this is a bit of a shame, IMO, but I can understand it).

Here's an interesting way one project manages community updates to their wiki, while still keeping tight control, as for source code:

My proposed workflow is this:

  1. Manually create a fork of the Taffy wiki on your Github account:
    • Create a new repository on your github account. Let's call it "Taffy-Wiki".
    • Clone the Taffy wiki repo to your local machine somewhere: git clone [email protected]:atuttle/Taffy.wiki.git
    • Remove the original "origin" remote and add your github repo as new "origin" git remote rm origin and git remote add origin [email protected]:<YOUR_USERNAME>/Taffy-Wiki.git
  2. Make your proposed changes locally, then push them to your github account: git push -u origin master ('-u origin master' only required the first time; afterwards just do git push)
  3. Submit a ticket to the official Taffy issue tracker requesting me to review your changes and merge them in. Please be sure to include a link to your repo and describe what you've changed.
  4. Goto #2

(From How you can contribute to Taffy documentation.)

If it were me, I'd create an issue in the main repository (that is, the one you forked) suggesting an update to the wiki. If issues aren't enabled, then email's about the only other option I can think of.

Tags:

Git

Wiki

Github

Recent Posts