How can I make a pull request for a wiki page on GitHub?

Question

I saw a wiki page on GitHub that isn't open for editing. Then I forked the project, edited it on "my end" and tried to do a pull request. It turns out, the wiki isn't in the project, and there isn't a way to commit changes to it.

Other than e-mailing, is there a way to proceed if I want to suggest a change on the wiki in this case?

^{At this point I found out what seems like an alternative under "Questions with similar titles", but I couldn't do the pull request with it yet, and so I'm not sure submodules is a good way for this purpose. I now see I could probably branch it somehow... So is this the way to go?}

Answer 1

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 git@github.com: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 git@github.com:<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.

Answer 2

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/she also has the documentation with the code. He/she can change both in one PR and all gets reviewed in the same process, so after merge, code and documentation 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
• Architecture
• devon4j, Architecture
• devonfw for Java 3.2.0 (2019)
• devon4j/.travis.yml

Answer 3

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 taste, but Risk-First is mainly a wiki with a few Jekyll pages in the main repository.

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 repository and then pushing to both the main repository and the wiki, which Git supports fine with multiple origin URLS:

localhost:website robmoffat$ git remote show origin
* remote origin
  Fetch URL: git@github.com:risk-first/website.git
  Push  URL: git@github.com:risk-first/website.wiki.git
  Push  URL: git@github.com:risk-first/website.git
  HEAD branch: master

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

How do you merge two Git repositories?

And then push to both repositories like this:

Git - Pushing code to two remotes

Answer 4

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.

Wikis on GitHub are full git repositories, so you can treat them as such. Therefore, the following works.

In short:

They just need to clone your wiki page repository, (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 repository. That will bring in all of your wiki changes into their wiki.

Full instructions:

(Copied from Larry Botha's GitHub gist here: Merge wiki changes from a forked GitHub repository):

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]

# Check out 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

Answer 5

If you are ok to have a single page long document (I actually like it more), you can hijack the README.MD and put the content of the wiki there.

Not only it will be tracked as part of the normal repository, it will also be displayed on the home page.

It can be made to start with a quick reference and then get into more detailed description/instructions, so that the regular users will hit first the more generic information.

Answer 6

In addition to the @Gabriel Staples answer, you could also create a git patch file and attach it when you create an issue on the upstream repo. That way they can easily apply it...

Answer 7

GitHub now supports this and you can find details at Adding or editing wiki pages.

It's treated as a "normal" repository now, with branches, pull requests, commits, etc.