For the curious, this is an open source fork of RhodeCode starting from the last version before it went business source (so 1.7.2) that popped up in July 2014. It's nice to see that they are fixing a lot of bugs now instead of code cleanup resulting from forking. It would be nice to have an easy to find page of all the releases and changelogs though.
No, but I have seen it linked around quite a few times. I still need to give it a try eventually.
I'm a Java-guy myself so using GitBucket saves time. All of the VM/compiler requirements for building& hosting it are already on all of my servers. It also adds a safety net for myself: if I find a bug, I can fix it myself without too much hard work. It's just extremely convenient for my use cases.
I've heard nothing but praise for Gogs, so I definitely want to give it a..... go some time. (I'm sorry, needed to make that pun).
I did some semi-extensive research to find something to use in-house for our mercurial repositories (with potential to switching to Git because so much more is available). I went with Phabricator which also supports mercurial and is free to setup in-house. It's quite a spectacular product, I recommend checking it out. Kallithea needed an update (especially for UI), but the capabilities and the look&feel of Phabricator make it very useful.
Not great that on the homepage you're greeted with "IMPORTANT SECURITY NOTICE" with a massive security vulnerability in previous versions. Obv. that stuff happens but not a good start.
Kallithea is a fork of an existing codebase (RhodeCode) ... so this is not exactly a "start", although to be fair I'm not sure if the issue on the homepage existed before the fork or was introduced afterwards. At least one other security issue was discovered and fixed that existed (exists?) in RhodeCode as well: https://kallithea-scm.org/security/cve-2015-0260.html
At least they are quite upfront about the issues, and IMHO I'd rather see this kind of thing in a 0.1 version than a 1.0
Especislly since the real security is that you can apparently change your email address without a validation email being sent. All they did was add CSRF protection but this still is very bad practice.
Kallithea is community developed under a GPL v3 license. There is no corporate entity primarily in charge of Kallithea development, and there is no for-pay enterprise edition.
Just wanted to add that in principle the GitLab core team is in charge of GitLab development https://about.gitlab.com/core-team/ It is a bit theoretical since many core team members do work for GitLab B.V. (of which I'm CEO). By the way, does Kallithea have any features that are in GitLab Enterprise Edition but not in GitLab Community Edition?
Hi rtz12, I try to be informative and listen to fellow commenters. I'm sorry to hear that you perceive it as you do. My impression was that the quote 'corporate entity primarily in charge of Kallithea development' was a reference to GitLab as it is the largest (and only?) open source product in this category with a corporate entity. I wanted to make sure everyone knew about the role of the core team. As the CEO I think about GitLab a lot and I try to be present everywhere it is discussed on the internet. Coincidentally my last comment on HN was on an article about Twitter without any comments https://news.ycombinator.com/item?id=9361159 But I certainly comment about it a lot of HN. Actually our company got started by a Ask HN post.
don't worry, they are just meaning us (the RhodeCode company which was co-founded by Marcin, the creator of RhodeCode, and me).
The Kallithea project members have their own thoughts how professional enterprise software should be developed, tested and maintained for a massive scale and they do not think that a company or full-time employees should be involved.
They forked our old 1.7.2 version from 2 year ago.
It is good that successful open source projects are forked, it increases diversity and choice for all the different user segments and generally drives innovation forward.
RhodeCode Enterprise 3, https://rhodecode.com, is a significant improvement to our old forked versions (in terms of performance, security, workflows and VCS support) and the user can select now if he wants to go more for a hobby open source fork project or a commercially backed, professional software product like Gitlab or RhodeCode.
I wish all the best to the Kallithea folks even if it seems that their focus lays more on talking about why the project exists instead of working in the project itself and it is interesting to see how strongly the development paths already diverged.
> The Kallithea project members have their own thoughts how professional enterprise software should be developed, tested and maintained for a massive scale and they do not think that a company or full-time employees should be involved.
> They forked our old 1.7.2 version from 2 year ago.
while you are bashing this project because of too much talk, I had a look at the Rhodecode site and couldn't really gather any information about the project at all. Maybe I'm dense, but as far as I can see
- there is no description of supported workflows (branch/commit/patch-based, how do you track rebases/force pushes, etc.)
- there is no link to actual documentation
- there is no demo
- and worst of all: your "Pricing" section does not mention any actual prices.
I know I can directly download your software and try myself, but this is something I only do when I'm confident your software could at least theoretically work for our setup and is also affordable.
Hi Sebastian, thanks for the response, it makes a lot of sense that the comment referred to RhodeCode and not GitLab. I feel stupid for thinking otherwise, rtz12 is right that I'm a bit GitLab obsessed.
Think of it in terms of free software identity politics, or free software deontological ethics. In these terms lack of a multi-stakeholder copyleft (or single stakeholder committed to free software) invites identity crisis or immoral behavior, and presence of an enterprise (ie proprietary) version is identity crisis and is immoral. Therefore in those terms, the argument you're replying to is in favor of Kallithea.
If you're not thinking in those terms, the argument you're replying to might seem irrelevant, or even in favor of Gitlab, if eg you prefer a permissive license or the software you use to have a profitable business behind it. Maybe that's where you're coming from?
kallithea is lighter in pretty much everything. It doesn't have issue tracking, pull requests are simpler, etc; however, it works pretty well. If you have ever tried rhodecode, this is basically rhodecode 2 with all the commercial stuff removed and replaced by kallithea's own code (things like css or images were copyrighted).
Does anyone know an existing good way to version data rather than files?
I know of datomic, but it has time as a dimension - EAVT. Would be interesting in some cases - financial data, content creation - to have both, the querying ability of databases as well as git style branching/merging.
So for example
blob = { id: 1, meta: { type: "paragraph" }}
// so you can query by meta.type
version1 = { content: "This is a example" }
version2 = { content: "This is an example" }
db.commit("master", blob.id, version1)
db.get("master", blob.id)
// { content: "This is a example" }
db.commit("master", blob.id, version2)
db.get("master", blob.id)
// { content: "This is an example" }
I'd say it would be better to compare Kallithea with Chisel (http://chiselapp.com/), which does actual hosting for Fossil projects. I see Fossil more as a VCS by itself.
I've been building a toy git-like system for my own amusement, so this is a timely post. It'll be fun to read and see how it works and how it compares to my own.
