I wish they would spend a bit more time streamlining the installation procedure and/or streamlining dependencies. It looks like a great product, but attempting to get it set up left me with the feeling that it's extremely bloated. And 2-4Gb recommended RAM is... a lot. I know, I'm bitching about something that they are giving away for free, but oh well.
We're working hard on streamlining the installation but for now the focus is on a reliable installation method for most situations. The recommended RAM is 1GB, see https://github.com/gitlabhq/gitlabhq/blob/master/doc/install... (I'm a GitLab.com co-founder)
Thanks for creating Gitlab. It helped us a lot internally. We were using plain Gitosis before. Now nobody gives a hoot about that anymore :)
My only request would be to focus more on stability. We run it for 1 year now and there were many problems with upgrades and various changing issues with the different versions.
So for us less new features but a better tested Gitlab would be great. Maybe some kind of "stable" release? Not sure...
Hi binderbizingdos, GitLab.com co-founder here. I'm glad to hear GitLab meets your needs. We know some upgrades have been painful, especially to 5.0 where Gitolite was removed. Since then we try to have smoother upgrades with complete documentation. Of course we can't avoid deprecation in major releases to move things forward. Each release is stable but if you want to be extra careful upgrade two weeks after release. But please let us know if there is anything specific we should focus on.
I think Gitlab kind of suffers from the Ubuntu syndrome when they were still pushing the non-LTS release as default. Many things were not tested long enough and would cause issues for many people while they were using it.
For example after one upgrade browsing the repos didn't work because apparently the Git version hat to be a specific version. I think this was neither tested nor is the Git version mentioned anywhere as a requisite.
Or with v5.3 the Git satellites would get into an unclean state sometimes and had to be cleaned out manually.
I took quite some time to find this out too.
So my suggestion: more polish and testing and less new features.
Suggestion noted, thanks. By the way, both issues you mention (git version and satellite state) are now in the gitlab:check rake task so at least they are easier to detect. I'll make sure that the git version is added to the readme.
The most streamlined installation is "apt-get install gitlab." ;) What happened with the ITP for an official debian package? All of a sudden it seemed like it ran out of steam in February.
Try not running it on ubuntu, or in a location that doesn't allow sudo to be setup to allow any command in quite the same way as the install docs assume.
I've a forked version of their startup script that doesn't use sudo for the init script (honestly wtf why is this so common redis does the same). sudo the init script don't sudo in init scripts. Meh, its not too bad I'm at the point of 15 minutes to upgrade between releases so its not too bad but yeah it isn't a trivial install.
Good to hear you managed to install without sudo. Does this mean you didn't create the git user? How did you solve the git@ urls for git over ssh connections? Did you use the init.d scripts?
Thats basically it, nothing overly special, just switched sudo for su mainly. I could test to see if i'm root and then su or then sudo but don't see a point.
I agree. In the installation manual most commands are 'sudo -u git', they run as the git user but they use sudo to make them foolproof (some people skip the instruction to login as the git user).
I guess it all depends on perspective. When I picked up Gitlab (18 months ago) -- the major competition was Gitorious -- which if you think Gitlab has a bad install -- you have no idea.
Gitorious _had_ (haven't looked at it recently, I guess they spent a lot of time addressing this) the worst install I have ever seen (any package, ever, 15+ year in the industry) ... it seemed built for complexity just to generate them consulting / professional support hours. Gitlab in comparison was blissfully simple.
As for the bloat... we have nearly 180 projects and 10+ user accounts, and while the baseline setup has a lot of bloat (I blame choice of language / framework) -- it generally works fairl well -- sometimes you have to kick Ruby.
The really annoying part is upgrading. Which right now the instructions tell you to do bit by bit instead of whole hog. If you end up behind it makes it harder to catch up, which seems like a bad thing.
GitLab.com co-founder here. As you noted you should upgrade version by version. This makes sure everyone uses the same upgrade path so the single focus of the community is on making that path rock solid. This is annoying when you are a lot of versions behind. Maybe you can already guess my recommendation, consider upgrading more frequent :-)
As a user, it doesn't look nice to hear this from the developers. I think it would be nice to have a stable upgrade mechanism that doesn't break anything for people - or maybe an automated mechanism that does all the upgrades step by step so the user doesn't have to do much.
Since I have seen this 'upgrade' problem repeatedly mentioned here, I think it would be a good problem to attack to help people feel more comfortable about using your product.
I recently set up gitolite internally and this thread interests me because GitLab looks like something that could be considered for Git hosting. However, someone in my place may not be so comfortable with the idea when I get the general feeling that "upgrades are a pain".
I only mean this as feedback to help you make your product more palatable (because I want to see a lot of good Git hosting solutions!)
Hi bloodorange, I'm sorry if I'm sounded strict. I agree that automatic updates would be very nice, but making these rock solid is not something we are comfortable with. Many people run GitLab with some kind of customization and we want to support that as well. We try to make upgrades as easy as possible but you do have to run each upgrade.
If bloat is a concern, I used to use gitweb (which is Perl) over CGI on a sharer server and performed very well for my uses. All I had to do was write a short shell script to create the repo on the server, and SSH was running for me anyway (especially if I was going to push-pull).
Now I use cgit, and discovered it a while before the Linux kernel did. [0] It is crazy fast (CGI written in C! Can you believe the nads on those guys?) and will be portable anywhere C is.
If only I could get git's smart HTTP working, but I could not find much on the internet to clue me in. Still pretty cool.
I don't know why they recommend 2-4 GB RAM, but we're running Gitlab on 512 MB with Phusion Passenger Enterprise just fine. It also helps that Phusion Passenger Enterprise happens to use the least memory among all Ruby app servers.
They continue to eschew using `foreman export` / `foreman run` / `bundle install --binstubs` in the docs, when it does simplify a lot of the installation / upgrade process. I've even sent pull requests that add capistrano / unattended deploy support that have gone nowhere.
I love the software, but the installation / upgrade docs are always hell compared to your average `git pull && bin/rake db:migrate && foreman export`.
Having said all that, I'm running it on an old box with 512MB of ran and it's tolerable.
GitLab.com co-founder here. Thank you for the suggestions. There is a proposal in the core team to switch to --binstubs. We will also move the run logic from init.d to the bin directory so you can also use it with monit/god/bluepill/omnibus/chef/foreman.
I set this up for use at my previous firm and it was extremely difficult and that was 2 years ago (so version 1 or 2 I think).
It was great once it finally was up and running but I'd only recommend it if you have a legitimate intellectual property concern and can't use github enterprise.
GitLab.com co-founder here. Installation got a lot simpler since 5.0 when you no longer had to install gitolite as well. I hope your upgrade will be smooth.
If you have problems with the installation use the free cloud service - nothing to setup. Or use vagrant (didn't try out myself).
It is a great product and 'my' users love it (finally convinced them to move on from svn). One can copy-paste the instructions, it's rather lengthy but never had problems.
It's always annoyed and confused me that GitHub Enterprise exists. GitHub is founded on the premise that open source is a good idea...yet for self-hosted git management the freedom-friendly solution is...GitLab.
So good for GitLab for existing at all, and congratulations to the team for releasing v. 6.0! May there be many more!
* GitHub Enterprise: $5000 per 20 users per year, effectively $416.67
per 20 users per month. (You have to pay yearly though)
* GitLab Enterprise: $39.80 per 20 users per month, or $398 per
20 users per year
* GitLab Community: Free
Basically, GL Enterprise is roughly 1/12 the cost of GitHub when purchased yearly, and 1/10 the cost if paying month-to-month (which GitHub doesn't offer).
Interestingly, GitLab is taking a page from GitHub's book and requiring customers to purchase user packs in groups of 20.
I remember working on LDAP integration for a SaaS product four or five years ago... I'd say that is exactly the sort of feature I'd expect to delineate a consumer/enterprise edition on.
Plus, base LDAP support is still in the community edition. Sounds reasonable to me.
Most of what that money buys you is the security and managerial comfort of SLAs and enterprise support. Community Editions scare the enterprise because when something breaks, there's no one on the hook to fix it (forgetting, of course, countless newsgroups, mailing lists and chat rooms usually dedicated to the topic). When GHE fails for some reason, your helpdesk can rest assured that within 4-24 hours (depending on SLA) you will have a fix that no one in the company is responsible for.
GitHub takes advantage of open source ideals to build its community...but doesn't open source its own software to give back to the community. It seems a little hypocritical.
I'd feel much better if GitHub had a useful open source core (like GitLab, or Chromium, or AOSP, or darwin, or...) and then had an Enterprise Edition that had enterprisey features (GitLab's LDAP integration is a great example) and professional support and such.
That's false. GitHub open sources almost all non-essential pieces of their codebase. [0]
Notably, grit [1] (git bindings for ruby), gollum [2] (wiki on git), and hubot [3] (chat robot).
To ask a company to open source their core, revenue-generating product is a little bit much. The reason Chrome can be open source is because Google Search isn't.
Google Chrome is not open source, you mean Chromium. Chrome is closed source and could contain all sorts of different code found in the Chromium project. Chrome is the Google branded version of Chromium. It is a minor difference but makes a major impact regarding your freedom.
I just wish GitHub Enterprise was a better product. When we did the 45 day trial (18 months ago) -- it was just awful, our repo got corrupted, no root access, had to talk to Github support for them to write us a "script". ugh.
Counter-anecdote: my company switched from a github.com organization to GitHub Enterprise and it was (is) fantastic. No corruption, great support, easy to manage, surprisingly fast upgrade cycle, etc.
Not trying to downplay the problems you seem to have had, just don't want to see the classic "complaints when things go wrong, silence when things go right" pattern with a product that I think is really great.
still, the github is not open itself. And we cannot expect that since they have to earn money to keep running that amazing open source platform.
Gitlab is great btw. Congrats
GitHub is a profit generating entity. I don't see how you can fault any business for trying to make revenue by providing a service. Either they charge, or they show ads like Sourceforge and Wikipedia. Bring morals into a world of capitalism is silly; everything good must pay the bills to be sustainable.
Ok. I see where you're coming from there, but understand that at least in the US, companies have a legal obligation to be unscrupulous money making machines. Nothing, not one thing, can come between the bottom line.
> at least in the US, companies have a legal obligation to be unscrupulous money making machines. Nothing, not one thing, can come between the bottom line
Might want to talk to Amazon about that[0][1]. Also: nope[2].
Seriously - If you claim that you have to be an immoral asshole corporation driven by nothing but monetary success, you can find all sorts of reasons for it and the more money you have, the more you can invest in making it seem like you're "just following orders". But the main reason is that you're an sociopath and care more about money than you care about people. And yes, those people are destroying the fabric of our society proportional to the amount of money and power they wield.
I don't think asking for GitHub source to be open is the same thing as asking for a free service. They can charge all they want for using their service while having an open-source version for those who want to host it themselves.
Every time I see a new GitLab release I get excited to install it. Then I see the install instructions and immediately give up. The number one thing GitLab needs is an easier way to get it setup.
If you've dealt wih servers and played with rails it should be pretty trivial for you to set up gitlab. Remember it's open source so before you say it's too hard there are paid alternatives that have one click installers.
Gitlab is a fantastic project and it would be worth the time getting it installed.
GitLab is a fantastic project and it is open source but that needs to stop being an excuse for how terrible an install process it has. It wouldn't be a problem or me to install it but it is a huge barrier for many people using it.
GitLab.com co-founder here. Thank you for commenting. We're looking into packaging but this will take some time. Maybe you can try the Bitnami images (http://bitnami.com/stack/gitlab), they are already upgraded to 6.0.
Taking a look at the installation process, and it is pretty much trivial, but long. The developers could try creating an apt-get package for even simpler installation.
It is as simple as copy and paste, make some small modifications to the configuration file and you go from a stock Ubuntu server install to having Gitlab up and running.
to a non-sophisticated user, following instructions (which they may or may not understand the reasons for) instead just running a single executable is complicated.
We run this at work, switching from Gitorious actually, and so far everyone on the development teams has been really impressed. It is fast, works well, and the web interface provides everything we need, and more.
We use Atlassian Stash at work after having tried a bunch of different git review & merge tools, including Phabricator, GitLab, Gerrit and more. Atlassian's Stash provides the best code review tools like per file diff + commenting. GitLab was our second choice but unfortunately it doesn't handle bigger diffs (feature braches etc) well. Maybe if a GitLab-dev is reading this, we need per file reviews! (And better notification settings!)
GitLab.com co-founder / GitLab core team member here. Thanks for detailing your needs. Many people use GitLab merge requests to do large code reviews for feature branches. These can be up to 100 commits and include per file diffs with line commenting. How many commits are your feature branches? We now have notification settings per project and mentions in issues and merge requests, would you want anythings else regarding notifications?
I coaxed the team at uni over to git by installing Gitlab. The ease of a web interface to view the repositories impressed even those academics who version control by copy and pasting folders of their code and adding a '_works' suffix. It also allows the SVN users to start using git as it was based on a client-server model.
The gem dependencies are incredibly large, but I found the install process well documented.
Tried a few Gitlab versions, stick with Redmine for now, though I do hope Ubuntu to support newer Redmine versions, which should not be too hard, but most plugins are not catching up with newer core releases.
"Today we present a new major GitLab version. There are a lot of improvements to make GitLab even more awesome."
I think the first sentence of every new release should at least explain what GitLab is. A new version of GitLab the tool for X,Y,Z. Some people will see a link to it in their tech news source of choice and think "oh that's interesting, let's check what it is"
GitLab Cloud gets our full attention. We just discovered that the majority of our income is from on-premises installations and generate revenue from that. Many of our now subscribers started with Cloud so we'll make sure to provide a great service.
They do use their own Gitlab installation for internal development. But they serve different purposes. Gitlab is used by developers accustomed to the project and Github to get new developers in.
Have you tried using `<table>` tags? Standard Markdown allows you to write arbitrary HTML tags in your text. I used it recently to write a table in a GitHub issue comment.
If GitLab doesn’t even allow you to use `<table>` tags, that’s probably not a problem with their Markdown flavor, but a problem with the sanitization step that runs after the Markdown compilation. Unless GitLab is using a broken implementation of Markdown that doesn’t allow any inline tags.
