Fun to see this on HN! I originally created Gollum to power GitHub's wiki system and wanted to see if we could use Git to make our wikis more powerful AND more open. I thought it would be cool if you could just clone your GitHub wiki and modify it locally or export it to some other system if you needed, or have it all locally for an airplane trip without wifi.<p>Another interesting thing is that I used my Readme Driven Development method to develop it, which you can see in the Readme of the first commit: <a href="https://github.com/gollum/gollum/commit/c7875704971be998a5399ce83e66a5dada03aad4" rel="nofollow">https://github.com/gollum/gollum/commit/c7875704971be998a539...</a>. I wrote it before writing a single line of code and found it worked nicely to figure out the API and feel out the ergonomics of the text format. More on that approach here: <a href="https://tom.preston-werner.com/2010/08/23/readme-driven-development.html" rel="nofollow">https://tom.preston-werner.com/2010/08/23/readme-driven-deve...</a><p>Glad to see the project alive and well!
I like the look of this a lot, particularly the support for running-from-local. I think git is <i>such</i> an ideal backend for something like a wiki, where multiple contributors and version history are both so important.<p>Tangent: how do HN folks generally do technical wikis -- or really, just keep track of the technical details of your software -- in large software development organizations?<p>My org uses Confluence for some stuff, Github pages and READMEs for others. It's... fine. It's not the worst I've ever seen, you can find some useful stuff with a little bit of work and some knowledge about where to look, but it's still very likely that whatever you're reading is either outdated or now-irrelevant.<p>How do you (and your team) solve the challenge of keeping documentation actually relevant and up-to-date when there are so many people writing so much code, then leaving two years later?
I wrote a book for O'Reilly about GitHub and their API and for some reason no one noticed that we added a chapter on Gollum (there isn't an API to access Gollum on github). It was the weakest one of the chapters, IMHO, but, you know, deadlines. O'Reilly was gracious enough to release it under CC, so you can read that chapter (and the whole book actually) here:<p><a href="https://buildingtoolswithgithub.teddyhyde.io/chapter-03-gollum.html" rel="nofollow">https://buildingtoolswithgithub.teddyhyde.io/chapter-03-goll...</a><p>There is a section on using Rugged, the ruby git library and how you can use that with Gollum.<p><a href="https://buildingtoolswithgithub.teddyhyde.io/chapter-03-gollum.html#using-the-rugged-library" rel="nofollow">https://buildingtoolswithgithub.teddyhyde.io/chapter-03-goll...</a><p>While writing this book, I found it really fascinating to learn about how git works by trying to manage a Gollum wiki. For example, if you add an image to multiple places in a repository, it only needs to store it once because git can tell it is already in there.<p><a href="https://buildingtoolswithgithub.teddyhyde.io/chapter-03-gollum.html#optimizing-for-image-storage" rel="nofollow">https://buildingtoolswithgithub.teddyhyde.io/chapter-03-goll...</a>
If you're new to Gollum, it's the software that powers GitHub's wiki tab in the repo view.<p>Gollum was one of the first Markdown wikis and still is a fantastic choice for running a Git Markdown-powered wiki. I ran a number of technical documentation sites on Gollum, and one of the things that set it apart was hackability. It was easy to modify it to do very custom things based on our site's needs.
Interesting!<p>Isn't it better to couple the documentation of a project to the source (e.g. in a `docs/` sub-directory) and just use markdown?
Wiki.js [1] is quite mature and nice as well, supporting bidirectional Git sync, a GraphQL api and search!<p>[1] <a href="https://js.wiki/" rel="nofollow">https://js.wiki/</a>
I have a strange obsession with git-powered wikis. I've spent time playing around with most of the popular ones and I think it's basically the perfect documentation format. However they all have their quirks and each one seems to be missing some major feature I want and it takes an unreal amount of self-control for me to not just throw my hands up and create my own, adding yet another one to the mix.
This was a fun weekend project. Thanks!<p>I will say, however, that getting it running took minutes; getting auth running was nearly a full day. Just HTTP Basic auth had me writing Ruby, then giving up and using a library that hasn't seen a single commit in years.
So many versions and rewrites of wikis.<p>github even has their own wiki system.<p>None of them support pull requests. (wikipedia supports patch/diff style manual change requests done via talk pages which is sorta gets you there, but not quite the github style automated pull request work flow i'd love to see supported)<p>Its honestly a shame.