Since there are so many threads already, here is a recap of the competition:
Self Hosted (in order of anecdotal popularity)
- Gitlab
- Gitea (fork of Gogs)
- Gogs
- Phabricator
- GitBucket
- Rhodecode
- Kalithea (fork of Rhodecode)
- GitPrep
- Allura
- GitSSB
- Pagure
If you want hosted Git, there are many competitors, but some of the notable are
- Gitlab
- Attlassian BitBucket
- Google Cloud Repositories
- Amazon CodeCommit
- Canonical Launchpad
- Sourceforge
All of which assume you want git, but other DVCSs are Mercurial (which is supported by a number of the above servers) and Fossil.
Which of them support code reviews modeled with distributed git objects? Maybe with git-appraise or something similar?
One of the annoying things, to me, is that the solutions I see all model code reviews as records in databases instead of doing something distributed and reusable.
Has anyone tried hosting one of the the self hosted services on an EC2 instance? What are the ~monthly costs? I'd really rather not have to do the admin work to maintain local hardware
Gitea costs no resources at all. I don't know EC2 because I self host (at home) but I've got an Intel Atom based server of 5 years old or so (costs 20W) and it runs great.
Self-hosted means you own a computer and you install their software on it. Hosted means they own the computer and run their software on it, but they allow you to have an account and store your code there.
If you don't know what you want, you probably want hosted.
Kallithea originated in 2014 [1] as a fork of RhodeCode 1.7.2 to rectify a licensing ambiguity that the fork-author felt arose in 2013. The GUI web interface was the most affected by hasty replacements, which perhaps explains the lack of polish in design.
RhodeCode continued to be developed, and in 2016 the RhodeCode Community Edition was re-licensed under AGPLv3.
Love the idea. The UI looks a bit dated. My recommendation would be to just copy what the main players have done as a starting point, unless you have a radically better UX solution. Then innovate from there.
Gogs is a visual clone of the Github graphic design, functions, menu structure, in short, just about everything from Github. SO sure, it works well and looks good, but uh.. its a total copy. Meanwhile Gitea has forked Gogs, as noted extensively very recently.
Regarding Kallithea, I installed and used it for work. I like Kallithea, although the features and interface are not as well developed as some alternatives discussed here.
Kallithea is far more lightweight to setup and admin that Gitlab, but not as full-featured as Gitea, which I recommend to anyone who asks.
I've been using Kallithea with 8GB+ binary Mercurial repos. It works on a server with 2GB of RAM and has been running for a few years now. If you want something lightweight that will work with huge binary repos (game projects and such), Kallithea is for you.
If anyone want to setup Gitea easily (but not in a docker container) I made a gist a couple days ago that install it and creates a service for easy management on ubuntu 16+
It would be even better if Kallithea or RhodeCode adopted the UI style shared by GitHub/Gogs/Gitea and friends. Then we could have the best of both worlds - good, well-known UI but with software that isn't as closely coupled to Git as some others are (and is lightweight with requirements)
This is not what you asked, but if you’re looking to host a static website by pushing to Git in particular, you might be interested in Netlify. They’re essentially a build step + static host. If you like Github pages, this might be up your alley.
Wander aimlessly through hundreds of pages of Google results until you find something loosly related to what you're looking for in a forum post from ten years ago by a person who doesn't seem to exist anywhere else on the internet except for this one forum -- and he's been inactive for eight years?
I think the question you were hoping to have answered is, "Why would you pick this over GitLab?". And potentially the discussion you wanted to invoke was, "Is there an advantage to going with a full free software solution as opposed to a product that is primarily proprietary, but has an open core?"
Personally, I think there is, but in the case of GitLab it may not matter. Now that there are some free software heavy hitters (Gnome and Debian) who rely on the open core of GitLab, there is some more assurance that this open core will not become a kind of cripple-ware try-before-you-buy situation. Those groups have enough horse power to maintain the open part of GitLab if they choose to do so.
Having said that, I think there is room for other free software entries in this space and I'm looking forward to seeing how it plays out. In some ways the acquisition of GitHub may be the catalyst necessary to get things started, and I think it's a good thing.
In a way AFAIK Gnome and Debian moved to GitLab, because, among other reasons, they did not have enough horse power to maintain their own solution - plethora of services. Of course if the GitLab would fold, they would maintain it, but I'm not sure they would be better off than before in case of work allocation at least.
If gitlab were to fold, they would probably move to whoever is the best candidate at the time.
While moving is very painful, the fact that git is distributed means that setting up camp somewhere else is pretty smooth. Even the headaches of the other stuff, such as issues et al, will probably be handled by whoever the new host is.
I'm going to give Fossil a try, mainly because it is the only thing I've seen that has everything that I currently want. I'm a little bit worried about the Cathedral/Bazaar approach... I really like the idea that every copy of the source code is an implied branch. However, I suspect that I will have few enough collaborators for it to be of any matter.
Their characterisation of GPL vs BSD licensing in the git vs fossil comparison is frustrating though. I wonder if there is a way to convince them to update it because it really reduces their credibility. I'm specifically referring to "the GPL license grants the right to read source code to anyone who promises to give back enhancements". This is just completely incorrect. From the GPL V3: "You may make, run and propagate covered works that you do not convey, without conditions". In other words, as long as you don't "convey" (distribute) your changes, you can do whatever the heck you want (including reading the source code).
When taken out of context, it does sound bad, but please include the entire paragraph, because it's clear that not as you describe.
> To a first approximation, the GPL license grants the right to read source code to anyone who promises to give back enhancements. In other words, the act of reading GPL source code (a prerequiste for making changes) implies acceptance of the license which requires updates to be contributed back under the same license. (The details are more complex, but the foregoing captures the essence of the idea.) A big advantage of the GPL is that anybody can contribute to the code without having to sign additional legal documentation because they have implied their acceptance of the GPL license by the very act of reading the source code. This means that a GPL project can legally accept anonymous and drive-by patches.
This entire paragraph is incorrect. You do not imply your acceptance of the GPL by reading the source code. You do not have to accept the license at all. However, if you do not accept the license, then you have no right to distribute the code. It is on conveyance (distribution) that the restrictions show up. There are absolutely no restrictions on what you can do if you do not distribute the code.
That whole section in their documentation is just weird, to be honest. There is nothing in the BSD license that requires you to sign additional legal documentation either. The fossil project requires copyright assignment to include your code in the project (many FSF projects require the same thing with their projects for similar reasons).
They should just delete that section so that they don't look like they don't know what they are talking about.
Edit: They could rewrite the section to say that by distributing the code you have implicitly agreed to the license. This is more or less true. The license actually hinges on the fact that you never have to agree, but that if you don't agree then you only that the rights assigned to you by copyright (see section 9 of the GPL v3). The bit that's weird is that there is absolutely no difference with the BSD license -- you don't have to agree, but if you don't, then you don't have a license. The only real difference is that the BSD license doesn't explicitly say so.
At first I thought they were trying to make a political point, but the more I look at it, the more I think they just want to justify requiring copyright assignment. The obvious question is "Why don't all those GPL projects require it?" So they came up with something plausible, but completely incorrect.
pre-Atlassian BitBucket was a lovely app, then they landed that Web 9.0 JS abomination redesign. Because waiting 30 seconds for uncached Javascript assets to load while on the clock is totally acceptable, when all you really need is 500 bytes worth of a Git directory listing to render.
Left feedback, no response. Left feedback again, still no response. Moved everything to GitLab.
It's really hard to see great apps like this (and Reddit as a more recent example) destroyed by.. seemingly.. people given too much time to do their jobs. I'm not a front end guy, but the feeling I get is that it has the same problem as backend. Can't just cobble a few well-tested Django views together any more, must have a 16-microservice mess to ensure the CV is fully padded. Makes me so sad
Man, Atlassian... they royally screwed up with SourceTree as well; v2 is unusable on many systems, to the point that myself and many users have downgraded to v1.
For a bit of entertainment, take a look at this open issue https://jira.atlassian.com/browse/SRCTREEWIN-7374 created on 01/Jun/2017. Yes, an issue that makes the product unusable for many users, that has been open for over a year now.
The biggest complaint that I've seen against bitbucket is the ties to Atlassian and the fact it is a closed source product. Most of the ones featured here are some form of open source or open core for GitLab.
Self Hosted (in order of anecdotal popularity) - Gitlab - Gitea (fork of Gogs) - Gogs - Phabricator - GitBucket - Rhodecode - Kalithea (fork of Rhodecode) - GitPrep - Allura - GitSSB - Pagure
If you want hosted Git, there are many competitors, but some of the notable are - Gitlab - Attlassian BitBucket - Google Cloud Repositories - Amazon CodeCommit - Canonical Launchpad - Sourceforge
All of which assume you want git, but other DVCSs are Mercurial (which is supported by a number of the above servers) and Fossil.