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

http://gitit.johnmacfarlane.net/

by fs111 • 14 years ago

82 39 14 years ago

gitit.johnmacfarlane.net

Tyr42• 14 years ago

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

ProNihilist2• 14 years 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• 14 years ago

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

kroger• 14 years ago

Ikiwiki is nice, here's the clickable link: http://ikiwiki.info

gwern3• 14 years 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• 14 years ago

So what motivated this? What do you see as differentiating you from ikiwiki?

trin_• 14 years ago

somehow reminds me of

https://github.com/scy/levitation

but that doesnt seem to have gone anywhere...

ajross7• 14 years 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• 14 years 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• 14 years 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• 14 years 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.

ajross7• 14 years ago

I'm not saying this is a software bug, I'm saying it's a broken platform.

The package tells me it's version 7.0.4, released 15 June 2011. It's the version currently packaged by Fedora, and it's barely a year old. Yet it's already incompatible with new software?

nandemo3• 14 years ago

Hmm, I don't think that's the case. Could you elaborate on why you think ghc's version is the culprit?

I've just built gitit using cabal-dev and ghc 7.0.3. So more likely it's just an old case of "cabal hell".

nandemo3• 14 years ago

If you just want to install the binaries, look for a binary package (Ubuntu's got one, so Fedora might have one too).

If you really want to install from source, try cabal-dev (worked for me, see my other comment) or virtualhenv.

exDM695• 14 years ago

You don't want to take any development libs from your distro. At most, take the compiler (if the version is good) and install the rest in your home dir. The libs that come with your distro are intended to support applications that come from the distro. Usually that means that the libs are quite old and developing or running new projects with those will fail.

For development work and reliable deployment, use the libs from your language's package manager (cabal, pip, easy-install, npm, cpan, rvm, bundler). For applications from your distro, use the packages in your distro.

exDM695• 14 years ago

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.

ProNihilist2• 14 years ago

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.

ajross7• 14 years ago

All distros are also volunteer projects who are happy to accept packaging submissions from the community.

And I don't understand the "new major change" bit. I have base 4.3, apparently gitit won't run without 4.4. Are you seriously saying that's a version bump comparable to Python 3?

applicative3• 14 years ago

This is puzzling. Did something instruct you that you needed to re-install cabal-install? You would already have had a copy as part of the Haskell Platform. You also already had `old-time` since it's part of the Haskell Platform too. Maybe something was overwritten in the `yum -y cabal-install`? There are several possibilities. It bugs me in any case that yum wasn't warning you that it had already installed `cabal-install`.

It is probably something very simple but would be much easier to figure out in real time, e.g. on the #haskell irc channel which generally handles such difficulties promptly. E.g. does a look at `ghc-pkg list` and `ghc-pkg check` suggest that something was broken?

(By the way, the comparison with Ruby and Python and Perl and Node is not that great; cabal is as much, or more, like `make` than `gem`, managing compilation, linking etc.; one uses it all the time locally where distribution is not in question; it looks like that is the aspect that you are bumping into.)

ajross7• 14 years ago

I didn't have "the Haskell Platform". So I got it from the same place I get all my other open source software, my distro. A quick "yum search cabal" told me where it was, I grabbed it.

And apparently it was "wrong". Becuase while it's "The Haskell Platform", it's not the correct Haskell Platform.

My point was much simpler than people here are trying to interpret: the Haskell world is a mess, and it's very complicated to get it running. So interesting tools like gitit (which I swear, I really wanted to try) don't get any attention. Expecting your audience to have the same bleeding edge copy of The Haskell Platform as you do is never going to work. Someone needs to actually do the work to package and distribute the software.

This is not true of Perl, or Python, or Ruby, or Node, all of which have recent packaged versions in the distro that run recent software.

eboyer• 14 years ago

tit?

kennystone• 14 years 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.

gwern3• 14 years 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• 14 years 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

modarts• 14 years 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• 14 years ago

For one, it uses markdown. There are not that many wikis supporting that.

uvtc• 14 years 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.

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

Related Stories