

Gitit is a wiki backed by a git, darcs, or mercurial filestore.  - fs111
http://gitit.johnmacfarlane.net/

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

~~~
exDM69
All distros are way behind on shipping Haskell and it's not very easy to build
from source because of the bootstrapping problem. This is being worked on.

However, your statement about Ruby, Python, Perl and Node is BS. Especially
Ruby is very hairy to get up and running unless you are happy with old
versions from your distro. Setting up the Haskell platform is not a lot more
difficult than tinkering with rvm and bundler and whatnot to get Ruby up and
running. Python is a little better because most useful libs are included in
the "batteries" that ship with the interpreter. But try to use a bunch of libs
and you enter virtualenv hell.

And whenever a new major change comes out, a new world of hurt begins. Ruby
1.9, Python 3 and Perl 6 transitions have been really painful.

If these languages work better, it's only because your distro package
maintainers spend more time working on it.

~~~
ProNihilist
I'm fairly certain I was able to just 'aptitude install gitit' on debian
stable, edit the config file and 'gitit -f gitit.conf' to be up and running.

~~~
exDM69
Exactly. You should be able to do that. The libs that come from apt should be
compatible with the applications that come from apt.

But you cannot grab some software sources from dev repos (e.g. git clone
gitit) and then install the required libs from apt and expect it to work. It
may work if all the dependency libraries are very mature and stable, but
that's not usually the case.

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

~~~
gwern
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
So what motivated this? What do you see as differentiating you from ikiwiki?

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

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

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

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

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

------
modarts
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
For one, it uses markdown. There are not that many wikis supporting that.

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

------
trin_
somehow reminds me of

<https://github.com/scy/levitation>

but that doesnt seem to have gone anywhere...

------
eboyer
tit?

