Kallithea: A free code hosting solution for Git and Mercurial
kallithea-scm.org
kallithea-scm.org
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.
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 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.
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.
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.
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.
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:
https://bitbucket.org/durin42/hg-git/issue/107/hg-git-pushes...
https://github.com/moparisthebest/unlimit-code/blob/master/r...
Also the name relates to RhodeCode: Kallithea, or Καλλιθέα, is the name of a locality on the island of Rhodes
[0] https://kallithea-scm.org/repos/kallithea/changeset/24c0d584...
[1] https://kallithea-scm.org/repos/kallithea/changeset/564e4082...
[1] https://www.FreeBSD.org/ [2] https://phabric.FreeBSD.org/
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.
[0]: http://hglabhq.com/
https://github.com/moparisthebest/unlimit-code/blob/master/r...
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.