Live data from Hacker News

Gollum – A simple, Git-powered wiki with a sweet API and local frontend

github.com

21–30 of 44 posts

Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend

#21
post #14

If you're new to Gollum, it's the software that powers GitHub's wiki tab in the repo view. 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.

Are you sure? This statement in the docs makes it sound like it’s more of a clone.

> Gollum strives to be compatible with GitHub wikis (see --lenient-tag-lookup)

Edit: Looks like the answer is yes if you look at just /gollum.

> Gollum is a simple wiki system built on top of Git that powers GitHub Wikis.

Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend

#22
post #20

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. Another interesting thing is that I used my Readme Driven…

I never knew that my default approach is called readme-driven development :)

Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend

#23

Interesting! 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?

My docs often end up being related to multiple repos. So, although I want my docs in git, I’d prefer them to be their own repo.

Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend

#24
post #13

I've used gitit and it is pretty nice. Why do we need another one of these?

> gitit is pretty nice. Why do we need another one of these? Gollum and Gitit have both been around for more than a decade. Thousands of stars, hundreds of forks, and active commit histories spanning more than ten years suggests the world views both as of value.

If this program has been around for 10 years, then unless there is some news about it, it should have (2011) or whatever in the link title.

Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend

#25
post #3

Earlier quoted context omitted.

I always find Confluence to be the place where docs go to die. There's very little motivation to keep it up to date and tends to be one or two people driving it. When they move to another team or job, then it gets abandoned. The things my team uses GitHub pages for tends to do better because devs don't object too heavily to writing code comments (for generated docs), markdown (for design docs), or API specs (for API…

To me Confluence's problem is the not-very-relevant search, which either gives me generic blank documents that someone created as a placeholder (?!? -- I've started suffixing these with (blank)) or fails to find synonyms or related words when I can't quite come up with the exact search term (wonder if these "related words or synonyms" could be manually added...) I'm sure it is a difficult problem but I haven't really…

> gives me generic blank documents that someone created as a placeholder ... fails to find synonyms or related words ... Add lots of tags

These kinds of problems can be solved using neural networks as the foundation for search (variously termed "neural information retrieval" and "semantic search"). I worked on this at Google Research from 2016-2020, before launching ZIR AI in 2020 to make neural search available as a PaaS, just like Elasticsearch and Algolia have done for keyword matching.

Here are a couple of introductory pieces if you're interested in learning more:

[1] https://blog.zir-ai.com/the-high-cost-of-keyword-search, "The High Cost of Keyword Search"

[2] https://blog.zir-ai.com/semantic-search-helps-chatbots-answe... "Semantic search helps chatbots answer more questions"

Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend

#26
So many versions and rewrites of wikis.

github even has their own wiki system.

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)

Its honestly a shame.

Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend

#27

So many versions and rewrites of wikis. github even has their own wiki system. 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) Its honestly a shame.

[deleted]

Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend

#28
post #3
post #2

I like the look of this a lot, particularly the support for running-from-local. I think git is such an ideal backend for something like a wiki, where multiple contributors and version history are both so important. 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? My org uses Confluence for some…

I always find Confluence to be the place where docs go to die. There's very little motivation to keep it up to date and tends to be one or two people driving it. When they move to another team or job, then it gets abandoned. The things my team uses GitHub pages for tends to do better because devs don't object too heavily to writing code comments (for generated docs), markdown (for design docs), or API specs (for API…

I concur about confluence being where things die. There's a dev on our team that is very big on confluence whereas I'm not. Ironically, I am big on documenting our public methods from the perspective of a user of our library whereas he puts javadocs on private methods. He has more experience than I do, so I don't fight him on it, but man do I find it futile.

Re: Gollum – A simple, Git-powered wiki with a sweet API and local frontend

#30
post #3

Earlier quoted context omitted.

I always find Confluence to be the place where docs go to die. There's very little motivation to keep it up to date and tends to be one or two people driving it. When they move to another team or job, then it gets abandoned. The things my team uses GitHub pages for tends to do better because devs don't object too heavily to writing code comments (for generated docs), markdown (for design docs), or API specs (for API…

To me Confluence's problem is the not-very-relevant search, which either gives me generic blank documents that someone created as a placeholder (?!? -- I've started suffixing these with (blank)) or fails to find synonyms or related words when I can't quite come up with the exact search term (wonder if these "related words or synonyms" could be manually added...) I'm sure it is a difficult problem but I haven't really…

confluence's main problem is that it is being used by enterprise software people doing enterprise software baloney.
Post reply on HN