215

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?

Improve this question
6

8 Answers 8

Reset to default
153

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.

Improve this answer
4
  • @Chi-YoungJeffreyLii Those commands aren't mine but come from the blog post I quoted (I linked the source below the quote). They're command-line Git commands, which should work on any platform with Git, including Windows, and including a UNIX or GNU/Linux OS with the Bash shell.
    – Calrion
    Commented Jun 9, 2016 at 23:24
  • Nitpick: The origin remote remove/add sequence is perhaps a tad (unnecessarily) convoluted, plus the "fork" is technically not the origin so the name is misleading. I suggesting only adding a second remote on the local clone for the new personal GitHub repository (e.g. named "personal") and push to it normally. That way one can also still fetch from the real origin repository normally to synchronize with the work of others.
    – tne
    Commented Apr 4, 2020 at 17:56
  • This is all too much for me. I just clone the wiki, commit my changes locally, create a patch off that commit, and submit the patch in a Discussion or Issue.
    – mcp
    Commented Feb 27, 2023 at 2:12
  • Please vote for github.com/orgs/community/discussions/50163
    – Étienne
    Commented Nov 13, 2023 at 13:36
21

Unfortunately github does not offer PRs for Wikis. However, we have found the best solution for the problem so far in our github project (see e.g. https://github.com/devonfw/devon4j):

  1. Put your documentation into the Git repository together with the code inside a documentation folder.
  2. Add a Github Action workflow with some magic that stages all changes from that documentation folder with transformations applied to the wiki Git. See example link 8 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:

Improve this answer
5
  • 1
    This is probably good advice for how GitHub projects should manage their wikis, but it doesn't really answer the question about what a contributor should do for projects that don't follow this pattern.
    – jamesdlin
    Commented Mar 26, 2022 at 4:44
  • The first link is broken (404).
    – Peter Mortensen
    Commented Oct 21, 2022 at 20:33
  • We have meanwhile switched from Travis-CI to github actions: github.com/devonfw/devon4j/blob/develop/.github/workflows/… Also I can recommend to use antora.org for more advanced sites. Indeed this is more the hint for the maintainers side. The original question was answered by @Calrion
    – Jörg
    Commented Oct 22, 2022 at 22:12
  • This answer is a joke. You're not answering the question at all and are here simply to shamelessly promote your company. This should be deleted...
    – adamency
    Commented Feb 1 at 11:31
  • The simple answer is "github does not support PRs for wikis". This is not very helpful as people looking here want a workaround for the problem. There may be 2 PoVs: developers providing a github project and contributors wanting to create such PR. For the first group I wrote my answer since I had the same problem and it took my team months to find an acceptable and working solution. The workflow we have created has also been adopted as other answer to this question. Also the upvotes for my answer are IMHO showing that it has been helpful for some people. What company do I promote?
    – Jörg
    Commented Feb 9 at 22:19
7

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: [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 repositories following this:

How do you merge two Git repositories?

And then push to both repositories like this:

Git - Pushing code to two remotes

Improve this answer
1
  • FYI, I stand by this approach - it worked out pretty well. However, for completely different reasons I ended up migrating the whole lot into Jekyll so this isn't how riskfirst works anymore
    – Rob Moffat
    Commented Feb 8, 2019 at 17:22
7

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 independent 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

See also

  1. A very beginner-friendly answer I just wrote: On GitHub, can I fork just a wiki?
Improve this answer
15
  • Unfortunately the above approach doesn't work as the Wiki in the forked repo remains empty.
    – monochromec
    Commented Oct 9, 2023 at 11:54
  • @monochromec, the wiki is a repo. It is an independent, standalone, git repo. So, clone the original wiki repo, then set an upstream pointing to the new wiki repo, and push to it to get all of the wiki copied to the new repo's wiki repo too.
    – Gabriel Staples
    Commented Oct 9, 2023 at 20:08
  • @monochromec, if the code repo you are talking about is public, send me the link, and I'll clone it and do it to show you the exact steps. When I say "wiki repo", I do not mean "repo that has a wiki", I mean "repo that is a wiki, that is associated with some other code repo." Every git repo consists of two completely separate git repos: 1) the code repo, and 2) the wiki repo. It's just that most people (98%?) have never learned that the wiki is a separate git repo.
    – Gabriel Staples
    Commented Oct 9, 2023 at 20:09
  • 1
    @monochromec, I wrote a beginner-friendly answer: On GitHub, can I fork just a wiki?
    – Gabriel Staples
    Commented Oct 14, 2023 at 20:00
  • 1
    Excellent - that answers my question. Thanks a LOT for your step-by-step explanation!
    – monochromec
    Commented Oct 17, 2023 at 7:10
0

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.

Improve this answer
1
  • 1
    Thats good only for documentation that another tech user will read. If its for generic public, they don't want to scroll miles and miles of text.
    – Alynva
    Commented Oct 3, 2021 at 20:13
0

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...

Improve this answer
-1

All the other answers here either describe manual processes or involve Travis CI, so here's one with Github workflows.

Assuming you already have a wiki:

  1. Clone the wiki locally
  2. Copy all the files from the wiki repository to a "wiki" directory in your main repository
  3. Add a Github workflow file according to the README in https://github.com/Andrew-Chen-Wang/github-wiki-action

Now every push to the master/main branch results in the Wiki being updated and others can create PRs to update the wiki files in the main repository.

Improve this answer
-3

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.

Improve this answer
3
  • looking back at this question, i knew even back then that it didn't belong to stackoverflow because of the github specificity... but today i have a small regret for even insisting so much on using github! we need git solutions like sourcehut that promote open source while opening their source as well! even more so if they use agpl3+. in any case... thanks for the update. i don't know why i couldn't accept this as the answer now.
    – cregox
    Commented Jul 5, 2022 at 18:29
  • 3
    This is incorrect. Github does not support PR's for the wiki repo's directly. You'd have to follow @Calrion's answer above which would force you to replace the remote with your main repository's remote address and push your branches to it. At that point you can create PR's, which in turn would update your wiki.
    – b1kjsh
    Commented Nov 7, 2022 at 15:09
  • GitHub still doesn't support handling branches for the Wiki repository at GitHub. I.e. there is no Pull Request available.
    – Dennis
    Commented May 8, 2023 at 19:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.