I don't know anything about gitbucket, but gitlab is very well designed, and also has a public hosted instance at gitlab.com
That said, setting up your own instance is much more complicated than it should be. Taking a peek at the docs, Kallithea seems to be just `pip install kallithea` and then a couple of configuration files. Gitlab's installation process is much more involved, and it's really only appropriate for larger installations. Kallithea might be just as appropriate for small projects with 5 members hosting a repo on one of their home servers or VPSs.
I don't know how it was in the past, but installing Gitlab 7 on debian/ubuntu is a breeze: download a .deb and install it, install postfix, optionally tweak the configuration files, and run 'gitlab-ctl reconfigure'. Takes me less than 5 minutes. :)
Digital Ocean has a preconfigured GitLab droplet available. Costs $5/mo, I've been using it for over a month now and have had 0 problems. Setup was a breeze and I haven't had to do any complex maintenance tasks (aside from setting up a user for myself on the box, but I'd hardly call that complex).
As luck would have it someone made a dockerized version (sameersbn on github) of it. We've been using it at work for the past couple months without any hiccups.
It took a bit in the beginning because of a bug in one of the docker backends that was on by default, but following the guide he provided was simple. We opted to use the built-in redis and sql servers.
I'm using GitBucket and couldn't be happier ... We've got a GitLab installation at work, but for my personal projects I didn't want a front-end that relied on RoR (since I'm not proficient). GitBucket was reskinned with the modern GitHub look for version 2.0 and is written in Scala and run on a JVM (both of which I'm fluent in).
I should also note that I was a happy Gitolite user until it was obvious that having a web UI would speed adoption ... both GitLab and GitBucket provide the user and group mechanisms you expect.
They do however have many features which Kallithea doesn't have, so Kallithea is not a full alternative to those either. Depends on your needs.
However, you could just use hg-git[0] if you need Mercurial support. I haven't used Mercurial in some time now though, and I haven't used hg-git extensively, so I'm not sure how great the interoperability is.
You're right, if someone suggested Kallithea as an alternative to either of those, that would be a correct objection.
I have used hg-git quite a bit. The interoperability is pretty much flawless. There have been occasional hiccups when i updated a version of one component (hg, hg-git, git, dulwich) but not others, and everything broke, but it was usually quick to fix. The biggest problem was performance - for some reason, on large repositories, a push which would have taken a fraction of a second with git took tens of seconds with hg-git. And of course, you can't take advantage of all the powerful new features like changeset evolution.
Regarding the hg-git performance issues, I've been having them for a long time until I discovered somewhere a tip: every now and then run "git repack -a -d" on the git repo created by hg-git. It doesn't make it as fast as raw git but it makes a noticeable difference, from more than a minute to pull/push down to few seconds (that's with large repos with tens of thousands of commits).
Another issue I had been bitten by hg-git in the past is overwriting other people's commits when I push, as if it was running --force. Maybe that was a bug that had been fixed since but to be on the safe side I've been using an ugly workaround: have an intermediate local bare git repo where I pull from/push to and have it talk to the upstream git repo.
Aha, thanks for the tip! I'm no longer using hg-git, but i will try to remember this in case i ever do again.
I don't think i ever overwrote anyone else's commits, but i did push a load of deleted bookmarks. This was particularly annoying, because the repository in question was our Puppet code, in which all the branches are automatically checked out on the puppetmaster. Resurrecting 20 dead branches is a great way to eat a load of disk space. The bug is still open:
The FreeBSD[1] project is using Phabricator currently[2], at least for the Ports tree code reviews, but it doesnt seem to be used as repository host (it sits on top of their SVN repo) but for the diff views, discussions, approval process and so on.
i've been using Phabricator as part of contributing to GHC this past month, and the tooling is REALLY nice (haven't used the repo bits, but i expect its pretty nice too)
This is actually a fork of Rhodecode. This[0] changeset has most of the changes from Rhodecode to Kallithea. The repo contains the full commit his to Marcin Kuzminski's first commit of RhodeCode[1].
Also the name relates to RhodeCode:
Kallithea, or Καλλιθέα, is the name of a locality on the island of Rhodes
Not free at all, that's the reason for the Kallithea fork. When someone attempted to use Rhodecode apparently under the free promises, they got lawsuit threats:
cgit doesn't offer any features beyond viewing repository contents though correct? It certainly does a nice job at that though and is perhaps all some are looking for :)
darcs has been improving at a good rate and http://hub.darcs.net/ is good enough for me to use for my projects.
I use darcs because we would all enjoy more innovation if were to resist the inertia of the status quo and work on improving the tools we like. Unfortunately git's slipshod user interface design can't be easily fixed through incremental development and the underlying model won't be changed.
Interoperability with RhodeCode 2.2.5 installations is provided so you don't have to immediately commit to switching to Kallithea. This option will most likely go away once the two projects have diverged significantly.
Rhodecode started as hg-only and then added git when it seemed inevitable, but for those of us who still prefer hg, Rhodecode was the only thing we could use until the devs went crazy.
[0] http://gitlab.com/
[1] https://github.com/takezoe/gitbucket