We just moved over to Gitlab from just pure gitolite and it is such a great tool. Certain things like opening and assigning issues, wiki pages, merge requests, all on our private servers are amazing. I highly suggest running Gitlab on your servers if you're not comfortable with github or would rather have things on your own servers.
We used it for a Software Engineering project in college just this last semester. We were instructed that (as a fake client) that they needed a way to do internal reviews through a separate agency (all fake). Of course, we initially only used it to solve that issue in our fake software design, but the flexibility and ease of use caused us to replace the internal Comp Sci repository system with it. We're more than pleased with it. Both the faculty and students so far seem to enjoy it a lot more than the previous (decrepit) SVN system.
The chair of the department loves Git, but couldn't find a decent (open source) web solution that could be hosted on our systems (as in not Github). Gitlab is an amazing solution.
My guess: discoverability. Also, Gitlab is for self-hosted Git repos--probably aimed mostly at private projects, not open source. Gitlab itself is open source, so it seems logical to put it on the site that contains the largest gallery of open source projects in the world.
Still not quite right. Github enterprise requires that you pay Github to license the software and provide support. Gitlab is free and open source -- you can clone Gitlab and start doing git project hosting without paying or contacting anyone.
Akin to gitorious' rationale for not including an issue tracker. It is also targeting in-house development (and in gitorious' case, assuming will need to integrate with existing issue systems eg https://issues.gitorious.org/issues/41#note-11 says along those lines). Odd result is that Github is significantly easier to deal with for an open source project than are its open source alternatives.
If you're looking to poke around and try out Gitlab, it's very nice... but it has a few unsightly snags to install that will turn away 90% of people who just want to try it out... (including how to guides have the usual open-source vapidly miss obvious steps, requires a specific build of Ruby, etc), the latest version of Gitlab doesn't support certain versions of Ruby, and some required libraries are awaiting updating.
The best angle to go with is to download an appliance VPS with Gitlab already installed and fool around with upgrading it from there..
The difficulty in getting it to work with CentOS/RHEL is another problem for me. Focusing on Ubuntu is nice, but we run CentOS on our servers and even trying out the software on that distro is quite difficult.
Or at least it was when I tried it last week. Anyone have any success with that?
Just installed Gitlab successfully on RHEL6. Some modifications to the installation steps:
- I used RVM to install Ruby 1.9.3. This should be fairly straightforward.
- adduser command has a different interface on RHEL, but it shouldn’t be hard to figure out.
- I used Apache ProxyPass instead of Nginx. unicorn.rb needed to be updated to listen on a tcp port instead of a socket file.
- Supplied init.d script did not work out of box. Some modifications were required.
- Redis server was installed from REMI.
Let me know where you’re stuck and I can try to help you.
I agree that Gitlab is not very easy to install, as there are many complicated steps. The benefits of having a free private GitHub, though, were totally worth it.
Here are my notes for when I tried installing Gitlab on a fresh install of CentOS 6.3 a couple of months ago. It goes up to the point of running `rails server` to get you started, and the rest is like setting up a normal Rails application.
Yes. If something is difficult to install, even to evaluate, then people will not put forth the effort to try it out.
Their market is pretty niche: people who like GitHub, but don't want to pay for private repositories or need to host it themselves without paying for GitHub enterprise (or have some other need to host things themselves). So, they need to target developers who may or may not be familiar with sysadmin work. On top of that, their installation requirements are pretty specific, so if you don't have a system (or VM) with those settings, you're pretty much left to your own devices.
So, yes... I think 90% might be a reasonable number here. It might be a bit high, but it's in the ballpark.
The market definition has another substantially big segment other than the ones concerned with "pay" - the ones who are paranoid about keeping their repositories outside their company firewall.
My point was more that it's not hard to manage ruby versions. Certainly not for someone who plans to run their own gitlab instance. I think there is a very small population who are going to go through with downloading and preparing to self host a mini GitHub and won't Google how to manage Ruby versions...
I guess either way it turns into a moot discussion of, are they turning 90% of people away, or are they targetting the 10% since the other 90% don't/won't care or have the ability to maintain an instance.
My point is developers who can't just start using version control system of some kind, often end up not using source code control at all, or a technically inferior one that has issues when it comes to merging, corruption, etc.
When things "just work", more people uptake it.
Why? Development skills are not the same as Sys Admin Skills.
Github has been great to get people using source code control because it just works, including experienced devs, and new ones.
Still, everyone should be using source code control, no excuses. The only way to build that habit, early, often, for the newest and most experienced dev is to make it non existent to create and manage your repos. git init is fantastic.
What you're describing is akin to saying no one should drive a car if they can't design, improvise, fix, repair, and modify every part in the car themselves. It's just not something everyone spends a ton of time on, nor is it realistic, if I'm understanding you correctly.
There's little interest on my part beyond this on what is and isn't trivial.
That's not what I'm saying at all. I'm saying it would be silly for me to buy a broken project car because I know nothing about them and perfectly working cars are available.
The people you're taking about have probably never heard of GitLab. They're surely quite happy with GitHub.
It would be like me going on CraigsList and emailing my neighbor selling his in- pieces old sports car and asking what the hell I'm supposed to do with a car in pieces.
I feel like I keep having this same conversation and it's always about git. People wanting things to be easier does not magically make them so.
We've been using it a few months and really like it.
Now we're looking to integrate it with Phrabricator (http://www.phabricator.com/) which is a bit of a do-everything-goliath of systems but we hope will enable us to do some formalization of code reviews, security audits, and thus our deployment/release processes. (Ideally we want these cryptographically signed off on.)
Has anyone had good experience integrating GitLab with Phabricator or other external tools? Recommendations? Gotchas?
Phabricator and GitLab seem to have a lot of overlapping functionality (repo browsing, code review, wiki, issue tracking). What does GitLab add that Phabricator doesn't have?
We started off with GitLab so we're kind of used to it. It provides the following powerful anti-features: it's both more polished and far easier to use than Phabricator, which encourages lots of useful but esoteric and BOFH-style development processes like forced test plans, test coverage analysis, and pre-commit code reviews that take time for people to get used to.
Basically we're looking to leverage some more of these over time as we find the time to invest in the learning curve, without throwing away our lovely, easy to use, already functional, and far more polished GitLab system.
I've recently discovered GitLab and known only current UI. After seeing those old UI screenshoots I think previous interface was better. Current version is highly "inspired" by GitHub (which has very good UI imo) but somehow has worse UI/UX for me (but I'm using it only for a month or 2, so maybe it's just my first impression). I wish there was some kind of "theme" module for GitLab.
Agree. GoM did some design work a while back, but the gitlab project is moving forward at an incredible pace, so the GoM portfolio site is a bit out of date with the current state of affairs.
Not quite. Gitlab merge requests are very useful but only act between branches of a single repo, not across repos. Hence "merge" request, not "pull" request.
