I've been using GitLab myself and suggesting it to any clients with the proper infrastructure. When I found GitLab I tried it out, and finally ended up moving my SVN to Git (private projects). It's a great piece of software and I love the web hooks.
That's great to hear. Any way we can improve web hooks for you?
Dear open-source maintainers, a letter from GitLab
251–260 of 325 posts
Re: Dear open-source maintainers, a letter from GitLab
#252Re: Dear open-source maintainers, a letter from GitLab
#253Earlier quoted context omitted.
Yes but Bitbucket has unlimited private repositories. So if your company has lots of projects compared to lots of people Bitbucket's pricing model is better.
GitLab.com is completely free, and has both unlimited private repositories and unlimited collaborators!
1. Hosted Git. 2. Reliability.
There is none. I don't know why you seem to be trying to deny it. Your business obviously works with Enterprise. If I was a big corp, I'd be all over you. I'm not sure with Gitlab's compulsion with trying to make everyone happy. Even when they don't have a product that fit a nominal need in market (the 2 points above), they constantly try to insist that they do.
Re: Dear open-source maintainers, a letter from GitLab
#254Earlier quoted context omitted.
I said if I wanted hosted option, then their only reliable option is $390 onboarding. Which is true. If I must go on-prem, then I might just use git directly? Meanwhile at Github, $7 gives me hosted private repos. It's free on Bitbucket if I limit collaborators. The biggest selling point of these services is peace of mind and knowing someone is taking care of the code when I sleep. Otherwise, Git has always been a FO…
> If I must go on-prem, then I might just use git directly? Definitely. There's not much you can do with self-hosted GitLab that you can't do with pure git. GitLab just makes it easier, IMO. The main reason my company uses it is to restrict the master branch to certain people - doable with pure git, less effort with GitLab. There's no reason we couldn't use GitHub for this (wouldn't cost much for a team our size), bu…
The point I was making in the original comment was that Gitlab has absolutely no options without heavy onboarding that is hosted as well as reliable. I wasn't really undercutting their on-prem, just pointing out that comparisons with Github are heavily misplaced.
Re: Dear open-source maintainers, a letter from GitLab
#255Earlier quoted context omitted.
Thanks for your reply and for contributing code. 1. Shibboleth is now supported in the Omnibus packages https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/inte... 2. Hopefully you can use the packages now that the Shibboleth code is merged. 3. GitLab Pages, git push hooks, merge request approvals and audit logs are available in EE.
Note that point 3 was an answer to the question > What features of EE belong in CE in your opinion? which means rcarmo knows they're in EE, but thinks they belong in CE.
Re: Dear open-source maintainers, a letter from GitLab
#256For me the big things missing (not only for big open source projects) 1. more than one level of subdivision for groups/projects (see below) 2. groups of users (call it department/team): because of 1 we have a lot of groups, (because all the small libs are in separate projects, so the project itself is a group, but of course we have several projects), so everytime somebody join the company, we have to add him in every…
1. Nested groups should solve that in the future https://gitlab.com/gitlab-org/gitlab-ce/issues/2772
2. We're thinking about that but for now the invite other group feature in EE will have to do.
Re: Dear open-source maintainers, a letter from GitLab
#257Earlier quoted context omitted.
> If I must go on-prem, then I might just use git directly? Definitely. There's not much you can do with self-hosted GitLab that you can't do with pure git. GitLab just makes it easier, IMO. The main reason my company uses it is to restrict the master branch to certain people - doable with pure git, less effort with GitLab. There's no reason we couldn't use GitHub for this (wouldn't cost much for a team our size), bu…
True. There is no denying that on-prem Gitlab has its uses. Maybe not for me, but I can respect that. The point I was making in the original comment was that Gitlab has absolutely no options without heavy onboarding that is hosted as well as reliable. I wasn't really undercutting their on-prem, just pointing out that comparisons with Github are heavily misplaced.
Setting up your own instance is not hard [1], but we're also offering managed hosted instances on GitHost.io nowadays.
If you're still in the middle, you could use the one-click deploy options from providers such as Digital Ocean, Cloud 66 and AWS images [2].
[0]: https://gitlab.com/gitlab-com/operations/issues/42
Re: Dear open-source maintainers, a letter from GitLab
#258Earlier quoted context omitted.
If you're looking for Mercurial try out RhodeCode, it support all the Mercurial specific workflows like phases etc. RhodeCode actually supports Git, Mercurial, and Subversion.
Is Rhodecode completely open source like Kallithea?
Re: Dear open-source maintainers, a letter from GitLab
#259GitLab could differentiate their service by offering IPv6 support, which GitHub has so far declined to do.
Re: Dear open-source maintainers, a letter from GitLab
#260Earlier quoted context omitted.
Although we planned to switch to Softlayer we're still on Azure. It has given us a hard time, but in the last few weeks things have gotten more stable. Our availability is better (fingers crossed) but our speed is still unacceptably slow https://gitlab.com/gitlab-com/operations/issues/42
From first hand experience, Softlayer has been nothing but fantastic to us over the last few years, and cost effective.