7 ms·

Gitit is a wiki backed by a git, darcs, or mercurial filestore.

82 points by fs111 14y ago

Tyr42 14y ago
And you can have Literate Haskell Files directly. That's cool.
ProNihilist 14y ago
I've used gitit a fair bit for some personal things and I'm very impressed. Unlike doku-wiki it was still lightning fast when running off of an old EeePC 700 (630Mhz Celeron).
edward 14y ago
Ikiwiki is similar, it supports multiple revision control system backends including git and svn.
- kroger 14y ago
  Ikiwiki is nice, here's the clickable link: http://ikiwiki.info http://ikiwiki.info
- gwern 14y ago
  Yes, Ikiwiki was an inspiration to us: besides the goal of supporting multiple revision backends, John also took the idea of caching from it when we ran into performance issues on page loads.
  - gchpaco 14y ago
    So what motivated this? What do you see as differentiating you from ikiwiki?
    - gwern 14y ago
      Haskell, for starters. But more seriously, the motivation is to have a wiki with the capabilities of Pandoc: a bunch of formats -> a bunch of other formats. One comment already pointed out literate Haskell, which is nice.
      - dubiousjim 14y ago
        Pandoc is excellent. But it's also available for ikiwiki, since I did a quick port a year ago: <https://github.com/dubiousjim/pandoc-iki> https://github.com/dubiousjim/pandoc-iki>. I don't claim it's (yet) as well-integrated as it is with gitit.
trin_ 14y ago
somehow reminds me of https://github.com/scy/levitation https://github.com/scy/levitation but that doesnt seem to have gone anywhere...
ajross 14y ago
On Fedora 17: # yum -y install cabal-install # cabal update # cabal install gitit Resolving dependencies... cabal: cannot configure old-time-1.1.0.0. It requires base >=4.4 && <5 For the dependency on base >=4.4 && <5 there are these packages: base-4.4.0.0, base-4.4.1.0, base-4.5.0.0 and base-4.5.1.0. However none of them are available. base-4.4.0.0 was excluded because base-4.3.1.0 was selected instead base-4.4.0.0 was excluded because of the top level dependency base -any base-4.4.1.0 was excluded because base-4.3.1.0 was selected instead base-4.4.1.0 was excluded because of the top level dependency base -any base-4.5.0.0 was excluded because base-4.3.1.0 was selected instead base-4.5.0.0 was excluded because of the top level dependency base -any base-4.5.1.0 was excluded because base-4.3.1.0 was selected instead base-4.5.1.0 was excluded because of the top level dependency base -any Sigh. "Haskell Platform" indeed. If I can't get it and run it, I won't try it. Ruby and Python and Perl and Node make this work...
- BrianHV 14y ago
  Yeah, cabal isn't quite there yet. People are aware of the issues and are working on them, but it's a slow road. As a workaround, my modus operandi right now is to use virthualenv and build everything in there. I understand cabal-dev provides similar functionality, but I haven't used it. I've never had dependency conflicts when I build something from hackage in a virthualenv, so if you're still interested in trying it you might want to give that a shot.
  - kasbah 14y ago
    Thanks! I didn't know about virthualenv. Cabal's lack of uninstall, plus those dependency problems, will make this a must for me when I experiment with Haskell.
- cgibbard 14y ago
  This isn't cabal's fault. (Though the error message could certainly be clearer.) That message essentially means that your GHC is too old to build gitit, since the base package version is tied directly to the version of GHC.
eboyer 14y ago
tit?
kennystone 14y ago
What does the flexibility of the backend file stores buy me? It doesn't seem like I should care as long as it's easy to install.
- gwern 14y ago
  Other people will care. I edit my files directly as often as through a wiki, and I like being able to use Darcs instead of Git.
singingwolfboy 14y ago
I've started implemented a diff-based text storage engine for PostgreSQL. It accomplishes the same principle, but using Postgres as a backend, instead of Git. It's very rough, but I'd love to get some feedback! https://github.com/singingwolfboy/postgres-text-diff https://github.com/singingwolfboy/postgres-text-diff
modarts 14y ago
How many different ways of hosting a wiki page do we really need? What problem is being solved here that isn't solved by the multitude of similar options? (Not trying to be negative, i'm just trying to understand what problem/pain point is being solved by this tool that hasn't already been addressed)
- troels 14y ago
  For one, it uses markdown. There are not that many wikis supporting that.
uvtc 14y ago
Gitit is my favorite wiki software. One file per wiki page, and page source is formatted in (pandoc-)markdown [^1]. Also easy to configure and run. [^1]: Pandoc adds some oft-needed extras to classic Markdown, such as support for tables, definition lists, LaTeX math, and footnotes.

82 points by fs111 14y ago

Tyr42 14y ago

And you can have Literate Haskell Files directly. That's cool.

I've used gitit a fair bit for some personal things and I'm very impressed. Unlike doku-wiki it was still lightning fast when running off of an old EeePC 700 (630Mhz Celeron).

edward 14y ago

Ikiwiki is similar, it supports multiple revision control system backends including git and svn.

kroger 14y ago
Ikiwiki is nice, here's the clickable link: http://ikiwiki.info http://ikiwiki.info
gwern 14y ago
Yes, Ikiwiki was an inspiration to us: besides the goal of supporting multiple revision backends, John also took the idea of caching from it when we ran into performance issues on page loads.
- gchpaco 14y ago
  So what motivated this? What do you see as differentiating you from ikiwiki?
  - gwern 14y ago
    Haskell, for starters. But more seriously, the motivation is to have a wiki with the capabilities of Pandoc: a bunch of formats -> a bunch of other formats. One comment already pointed out literate Haskell, which is nice.
    - dubiousjim 14y ago
      Pandoc is excellent. But it's also available for ikiwiki, since I did a quick port a year ago: <https://github.com/dubiousjim/pandoc-iki> https://github.com/dubiousjim/pandoc-iki>. I don't claim it's (yet) as well-integrated as it is with gitit.

trin_ 14y ago

somehow reminds me of https://github.com/scy/levitation https://github.com/scy/levitation but that doesnt seem to have gone anywhere...

ajross 14y ago

On Fedora 17: # yum -y install cabal-install # cabal update # cabal install gitit Resolving dependencies... cabal: cannot configure old-time-1.1.0.0. It requires base >=4.4 && <5 For the dependency on base >=4.4 && <5 there are these packages: base-4.4.0.0, base-4.4.1.0, base-4.5.0.0 and base-4.5.1.0. However none of them are available. base-4.4.0.0 was excluded because base-4.3.1.0 was selected instead base-4.4.0.0 was excluded because of the top level dependency base -any base-4.4.1.0 was excluded because base-4.3.1.0 was selected instead base-4.4.1.0 was excluded because of the top level dependency base -any base-4.5.0.0 was excluded because base-4.3.1.0 was selected instead base-4.5.0.0 was excluded because of the top level dependency base -any base-4.5.1.0 was excluded because base-4.3.1.0 was selected instead base-4.5.1.0 was excluded because of the top level dependency base -any Sigh. "Haskell Platform" indeed. If I can't get it and run it, I won't try it. Ruby and Python and Perl and Node make this work...

BrianHV 14y ago
Yeah, cabal isn't quite there yet. People are aware of the issues and are working on them, but it's a slow road. As a workaround, my modus operandi right now is to use virthualenv and build everything in there. I understand cabal-dev provides similar functionality, but I haven't used it. I've never had dependency conflicts when I build something from hackage in a virthualenv, so if you're still interested in trying it you might want to give that a shot.
- kasbah 14y ago
  Thanks! I didn't know about virthualenv. Cabal's lack of uninstall, plus those dependency problems, will make this a must for me when I experiment with Haskell.
cgibbard 14y ago
This isn't cabal's fault. (Though the error message could certainly be clearer.) That message essentially means that your GHC is too old to build gitit, since the base package version is tied directly to the version of GHC.

eboyer 14y ago

tit?

kennystone 14y ago

What does the flexibility of the backend file stores buy me? It doesn't seem like I should care as long as it's easy to install.

gwern 14y ago
Other people will care. I edit my files directly as often as through a wiki, and I like being able to use Darcs instead of Git.

singingwolfboy 14y ago

I've started implemented a diff-based text storage engine for PostgreSQL. It accomplishes the same principle, but using Postgres as a backend, instead of Git. It's very rough, but I'd love to get some feedback! https://github.com/singingwolfboy/postgres-text-diff https://github.com/singingwolfboy/postgres-text-diff

modarts 14y ago

How many different ways of hosting a wiki page do we really need? What problem is being solved here that isn't solved by the multitude of similar options? (Not trying to be negative, i'm just trying to understand what problem/pain point is being solved by this tool that hasn't already been addressed)

troels 14y ago
For one, it uses markdown. There are not that many wikis supporting that.

uvtc 14y ago

Gitit is my favorite wiki software. One file per wiki page, and page source is formatted in (pandoc-)markdown [^1]. Also easy to configure and run. [^1]: Pandoc adds some oft-needed extras to classic Markdown, such as support for tables, definition lists, LaTeX math, and footnotes.