I have never used GitLab myself, but some of the features mentioned in the article (like a true voting system) is something I've really longed for. Might have to reconsider trying out GitLab more.
One issue that was raised several times was the ability to not create merge commits. In GitLab you can, as an alternative to the merge commits, use fast-forward merges or have merge requests be automatically rebased.
The main thing keeping me from actually doing it is the network effect... and this:
Disadvantages
Right now GitLab.com is really slow and frequently down. This is because of fast growth in 2015.
Thanks! We're very glad to be on the front page and hopefully get more people contributing and discussing features. GitLab.com is now at a size were the HN crowd doesn't make a dent. But the HN crowd is very important because they are frequently active contributors. We are trying to solve the speed of GitLab.com even if we grow 10x over a few months.
GitLab.com runs GitLab EE. So - if you compare features of github hosted and gitlab hosted, it's best to compare EE. (For example, GitLab.com hosts private repos, for free, and it's EE.)
There is already built-in support for pull request[1] and patch based workflows in Git itself. Why do we need to wait for, and choose based on, hosted services providing things like that? EDIT: for more clarity; using pull requests and patches with Git itself means that it simple to rebase or whatever, since you're just working with branches and patches directly.
Or am I missing something? Other than something like usability, perhaps...
[1] I'm not actually quite sure if there is a specific command for that format. Though it should be easy enough to have a third party solution that uses a format through email.
I hate that github does pull request merges with --no-ff, so what happens is that I manually pull the PR, merge it locally, and push. Github is nice enough to notice that the PR was merged, so its status is appropriately closed (if that was a fast forward, I don't think it detects rebases), but that makes me have to go out of the browser to start typing commands when I could have just clicked a button and be done with it. Essentially, it's a smoothness problem.
I think taking the conservative approach of not re-writing history (--no-ff) is appropriate for a service like github. It is easy to ff merge PRs from the command line.
A migration to Gitlab. GitHub would have to start fucking the developers asses in a serious and violent way for them to move to another place, the same way that the SourceForge -> GitHub move was done.
With VideoLAN, we're not on github, but I believe we fit the 'large open source project' description. We host VLC, FFmpeg, x264 and quite a few related libraries.
For VLC and all related VideoLAN projects, we're moving to our own instance of GitLab hosted on our infrastructure.
And to be honest, it's quite good, but a few stuffs are ridiculously limited, to the point that some people in the community are resisting the change.
The first part is the groups and subgroups: it seems incredibly difficult to give sub-groups access to repos (like a team for iOS, one for Android, one for libVLC... but all are under the "videolan/" group). It seems there is a way with the EE, but not in the CE; and the current idea for the CE is to have sub-projects, which is not good, because it will make our URLs way more complex than needed.
The second part is the bugtracker/issues tracker. We use trac for VLC, and we want to leave it for something better; but gitlab issues is way too limited, even when using the templates. Especially, it seems to be impossible to add custom searchable fields (like "platforms", "priority" or "modules") which are very very useful to do queries. Also, there is no way to do custom queries and store them ("I want all the bugs for Windows, which are related to the interface modules").
If I remember correctly, this second part was also a complaint in the open letter to github.
Finally, it's not really related, since it's more a feature request, but we'd love to allow external people to fork our repos, but not create completely new ones (or have them validated) because we don't want to host any projects under the sun (there is github and gitlab for that). So far, you either allow both features or none of them.
PS: can we have custom landing pages and custom logo in the CE version? :D :D
> Especially, it seems to be impossible to add custom searchable fields (like "platforms", "priority" or "modules") which are very very useful to do queries. Also, there is no way to do custom queries and store them ("I want all the bugs for Windows, which are related to the interface modules").
Isn't this use-case covered by Gitlab's issue labels?
We want for every bug, that a few custom fields are always defined, to do a partition of the bugs, and to be able to query on those. Moreover, to change the priority or the platform, it's quite complex to do and will break often. Many bugs won't have it filled, for example. Labels do not guarantee that consistency.
As you can see, it's already what people want in the github open letter.
Just curious, what options would be there for a platform filed? What I'm aiming at are issues that are present on all mobile platforms, all desktop platforms, all x86, ... etc. Either you'd have another dozen of cross-categories or you'd have to use something like check-boxes, which are essentially labels.
Maybe having some set of mandatory labels? I.e. at least one label from platform list, at least one label from priority list, etc...
If you have to create a label for every platform you support and every existing priority and module, the labels list will become really cluttered, making it hard to find things.
It becomes very long, but it doesn't seem overly cluttered, and it avoids the risk of overly restrictive either/or classification. Rust makes extensive uses of labels on github, they're up to 120 at this point[0] and it seems to work reasonably well even with old issues with a fair number of labels[1]
FWIW, at my office for the small projects we have tracked, we use a similar method.
type-label
Types:
b - bug
f - feature
p - priority
t - team
So we might have issues tagged "p-med b-confirmed t-group1"
Once there is a method to the madness, it's not bad, and it's more flexible on Gitlab's part I'm sure, to have people tag instead of supporting custom drop-down attributes.
I don't know gitlab very well, but I maintained a few trac instances - the thing about trac is that it is (was) an issue-tracker framework rather than a one-size-fits-all out-of-the-box solution. Have a look at:
And there's a lot of things available before adding custom plugins.
I'd be interested to hear what limits vlc hit in trac (and why they'd rather move than improve trac. Nothing wrong with that - but I confess I have a soft spot for trac and the team's ethos of "try it as a plugin before making it a core feature").
Also curious if anyone know what, if anything happened with the Apache Bloodhound fork/distribution?
I always hoped it held the promise of being a simple to install, opinionated trac for multiple (lean?) projects. But as far as I can tell it was pretty much abandoned.
While part of it might be rails-angst and fear of precious stones - I always felt gitlab was a bit of a heavy hammer in terms of install/dependencies/cloc for "just" project management.
In practice the bundled distribution alleviates that - but I still feel taking the "best of trac" and writing a new system a little more opinionated (and probably with a clearer data model) would be worthwhile. Just another project on the todo-heap :)
> Finally, it's not really related, since it's more a feature request, but we'd love to allow external people to fork our repos, but not create completely new ones (or have them validated) because we don't want to host any projects under the sun (there is github and gitlab for that). So far, you either allow both features or none of them.
On a technical level that seems an impossible distinction to make. Someone wanting to host a new project could just fork yours, then make a a commit that deletes everything currently in there, then start their new project.
Yet, there is still differences. Allowing only "fork" is a good and easy thing.
Having a fork that delete everything and start a new projet is easy to detect and label as spam. (there will always be abuses, but it's okay as long as you can mitigate/moderate)
I'd think it's pretty easy to have a policy that says "only VLC forks or VLC-related projects". What if someone wants to pull out part of VLC into its own library?
It would still send a signal of "please don't do that" - and could be "enforced" with some change/diff tracking in a cron job (all files changed removed - prompt someone to have a look, or just freeze access for a week/month then schedule for deletion).
On your own instance, disallow creation or restrict of further projects. Ask people to use the 'Import any repo by URL' feature in GitLab on their own instance / GitLab.com.
We're planning to add cross-server merge requests in the future, which would make it that you don't have to host the forks yourself [0].
Did you guys evaluate Phabricator? I wish more people knew it existed and wouldn't pick such "sideways" moves like GitHub to GitLab in an effort to be more "open source" philosophically speaking.
> we'd love to allow external people to fork our repos
I wonder if this could be solved by making it really easy to fork your repos, but when that happens the fork ends up (with tight integration) back on the/a public GitLab instance.
2. You can add custom labels on issues and the searches can be stored in urls that you can bookmark and use in links. You might have considered this already and need more functionality. Maybe it is best to discuss this in an issue so I created https://gitlab.com/gitlab-org/gitlab-ce/issues/10712 Please add there what you need in addition to the labels functionality. We addressed the long list of items raised in the original Google Doc letter below the signatures in https://gitlab.com/gitlab-org/gitlab-ce/issues/8938#improvem... The first item under improvements details our reponse to that question.
3. In GitLab you can give each user a fixed number of new projects. That should prevent people from storing a excessive amount of repo's. But feel free to make a feature request to limit people to only forks. As other replies have indicated that still allows people to work around it but at least the intention will be clear.
4. A custom landing page and logo is an EE feature http://doc.gitlab.com/ee/customization/branded_login_page.ht... We think this is more relevant for larger organizations so we're comfortable for having it as EE only at the moment. As mentioned under 1. we're open to offering you (and other open source projects considering self-hosting) a lifetime EE license.
I'll be in the comments today (just woke up in SF). You and any other open source project can always reach me at sytse@ company domain to get assistance or claim the EE license.
The whole idea of VideoLAN infrastructure migration from gitweb/trac/etc to gitlab and not to github was to use and promote free and open-source software.
Using closed-source software there is out of question, really.
This is really a problem I think. Maybe GitLab could reconsider to adopt a licensing model[1] for the Enterprise Edition that would make it more Free Software friendly?
[1] I.e. a licensing model based on GPL and selling services that Red Hat uses for RHEL, instead of a licensing model like they, and a minority of the "open source" companies, use.
When we introduced the Enterprise Edition we had it under MIT license. This caused much confusion with our customers. Maybe the situation is better now with companies like Hortonworks educating the market. But unlike others we want to make our open source edition as simple to install and maintain as the paid version.
My understanding from taking a Red Hat sysadmin course is that what you get from a RHEL subscription is firstly access to their repos from which to download updates and additional packages. The other, perhaps bigger, portion of a RHEL subscription is the support; I think they will answer the phone and provide you fixes for any bugs in RHEL-provided software relatively quickly. This is nice for companies, for whom uptime and stability are often superior to most other concerns, like staying close in feature parity to upstream.
Note that the accepted answer there is wrong, as it ignores the fact that the question asker wanted to distribute virtual machines containing the software, which is a violation of the GPL. The currently second answer by h22 is correct.
"This software and associated documentation files (the "Software") may only be
used if you (and any entity that you represent) have agreed to, and are in
compliance with, the GitLab Subscription Terms of Service, available at
https://about.gitlab.com/terms/#subscription (the “EE Terms”), and otherwise
have a valid GitLab Enterprise Edition subscription for the correct number of
user seats."
Thanks a lot for the answer and the proposal. But we do not want to have anything critical that is not open source. We try to promote OpenSource, so using non-open-source software is hard to do.
1. Thanks, but see above :)
2. As I said, custom labels are way too limited, as people on the open-letter-to-github said, so I will comment on the issue.
Thanks, I get that you don't want to be on proprietary code. I'm look forward to your email. And we're open to discussing open sourcing features if that is needed.
I don't know if that would apply to GitLab too, but maybe consider switching from the CE / EE model to just one "product" and a free for non-commercial model? Like e.g. http://3t.io/mongochef/download/ does it? I like that model way more than a feature-reduced version.
We considered that but we value having a completely open source version for all projects more. For more information about how we see the difference between CE and EE please see https://about.gitlab.com/about/#stewardship
What about having a single product, and charging for a proprietary license + support? This may work better with GPL as many large orgs are allergic to it.
With MIT license, many sites probably just implement the branding changes etc in the CE product on their own.
We want to give large orgs the option to run GitLab without having to pay us. We don't mind having people add features to CE, these are the same people that will send enahancements upstream and make GitLab better for everyone.
I'm pretty sure they take outside contributions for CE, so if that was AGPL3 they wouldn't be able to use it in Gitlab EE, which sounds like shooting themselves in the foot.
> If this is essential for you we'll give you a free lifetime license for GitLab EE.
While I get the sentiment, I don't think this helps. If you want to help the Open Source community, give us what we need in the form of open source. If I don't care about vendor lock-in I can go ahead and use GitHub. GitLab counts because its open source, and its open source version is the only thing the open source community should care about.
That makes sense and we want to make sure GitLab CE is a great solution for open source projects. If there is an EE feature that is would come up frequently in these conversations we would not hesitate to open source it.
this is probably not the right forum to express this on, but it's what's in front of me right now and it's topical, so here it goes:
I have seen the feature of being able to customize the login screen come up in discussions about gitlab come up so many times, in so many places, and I usually see it met with "EE feature" or a community member saying something like "gitlab is open source just change the files on your server".
This seems like such a basic thing for an open source software like gitlab to just provide out of the box, i can't believe it isn't listed under your " ... an EE feature that is would come up frequently in these conversations ... " that you "would not hesitate to open source". Especially since at least several of the people you're replying to in this thread have mentioned it specifically.
Is gitlab really making enough income from enterprises who decide that this is the killer feature that they need to pay for EE to get?
It seems like a simple matter of moving the gitlab branding on the login page to the footer with a "powered by gitlab" type of thing and a logo.
Please don't take my meaning as a hateful rant, I love gitlab and personally manage 2 seperate deployments of gitlab CE, but i am not ashamed of saying that this is something of a frusteration to me, and I have a hard time taking this
>If there is an EE feature that is would come up frequently in these conversations we would not hesitate to open source it
statement seriously in light of how many times I have seen this seemingly harmless feature shot down for essentially no real reason.
I'm still considering what to do with git.xiph.org and trac.xiph.org, and gitlab is one of the options. One thing I know for sure, just as with Videolan, a proprietary licensed solution like the EE is out of the question.
Instead of offering a free EE license I think the better thing to do is to open source features in EE that are deemed essential. So if you run a significant open source project and are considering switching to self hosted GitLab please let us know what EE features are blocking you (if any). This will allow us to open source them.
systse, I have nothing of value to add to this topic but as usual I want to thank you guys for the work you do. Gitlab may not be perfect but it's heartwarming to see an awesome open source project being supported like this and it's always really nice to see companies thrive on FOSS-first models.
Well, I can understand that having a business model which actually is stable and makes around FLOSS is hard, so I can tolerate a lot of wiggling around the edges of freedom. However, what I cannot tolerate is freedom of my data. Our IT guys are uneasy to installing supported version of GitLab internally (aside from the small question of money), because they are afraid that once we install EE version, we are locked into it. Is there a supported way how to get from EE to the true opensource version of GitLab and not to loose any data (aside from functionality not available in CE)?
Can I just take this moment to say I love VLC; it's one of the best and most reliable programs ever; it does EXACTLY what I want 100% of the time and I am always astounded to discover some neat feature that fits some odd need I have. To you and your team, thank you so much for making it so effortless to watch so many different things without having to worry about formats, codecs, subtitles, audio tracks being off, etc etc etc. Thank you so much.
My company with ~300 developers are moving to Gitlab in the next few months. Today our CTO/PM shared opinion about Gitlab and he was very happy we're doing it, even better I recommended it to him :)
I'm a Gitlab users for a few years now, personally I like it much more than Github, one of the reason is that I fear that Github contains too many projects and gains too much control over OSS, I also dislike their CoS.
> one of the reason is that I fear that Github contains too many projects and gains too much control over OSS
I don't understand this fear. All repositories on GitHub can be hosted elsewhere. Moving metadata (e.g. issues, milestones, PRs, etc.) is more difficult but mostly possible.
Disclaimer: I like that GitHub is the "central" place for OSS, it makes my life much easier. I know how to use the product very well and it's convenient having almost every project that interests me available there.
Monopoly. Github enforces their CoC which has nothing do to with good coding practices or technological progress, they ban repositories and people based on their views expressed in comments.
I still don't know how I feel about GitLab. My initial reaction was that they were an underhanded, cheap knockoff of GitHub. It felt kind of dirty, like they were stealing GitHub's thunder and giving it away for free. Then they started charging for enterprise features and turned it into a business, which felt even weirder. And then they raised a lot of money, which kind of made them seem more legitimate. And now this letter, which changed my perspective quite a lot. I didn't know that had features like voting on issues, and issue templates.
So now it even feels like they're doing Git hosting the right way, making the core software open source, and charging for enterprise features.
On the other hand, I would have probably never paid for GitHub if they followed this model. So I don't think GitHub would have been as successful.
We are dealing with a lot of sensitive data and code which is legally not allowed to physically leave our group and GitLab is in my opinion the best open source choice for that.
I feel its community edition is up to par with github in most aspects and it a was a change towards the better from our previous svn based solution (Redmine)
Yes, because not everyone uses Docker yet. Some may never adopt it. So long as that remains a viable path, then the matter of deployment systems and complexity is relevant.
I wonder why they advertise the "platform"/implementation language so clearly (in this case Go). It shouldn't matter for the users? I get sceptical, as if the only reason they exist is to provide the same service but in a new implementation.
I've been using Gogs for personal use for a while. I love its speed and its simplicity.
That said, it's probably not a good fit for most businesses at this point. It's relatively new, and mostly maintained by a single developer, who spent the last summer on vacation.
He's very active when he's around, and almost always working on improving Gogs, but there's a lot of people with features requests (the issue that's always getting comments today is for opening pull requests across branches within a single repository -- i.e. not forking.)
There's also Stash (now renamed to BitBucket Server (edit: fixed name, as pointed out in the reply)). It does not include some of the features (such as issue tracking), and I think rightly so. I haven't used GitLab for maybe 2 years now, so I can't compare the two.
Umm no, you are incorrect. Bitbucket does have its own issue tracker like GitHub.. (but it is not turned on by default) and what I am referring to is NOT JIRA Software.
I think you are right about how GitLab started. There is, and there should be, a lot of frustration about the biggest open source hub (GitHub) not being open-source themselves. This feels backwards and creates a harsh dictatorship that shouldn't be. GitLab tried to solve that by making an open source version and because it now can be improved upon by everybody new features start to appear. I love the self hosted aspect of GitLab and I think they should keep focussing on that however their instance of GitLab [1] is notoriously slow and unreliable. A hobbyist should not need to host their own repo, they should be able to rely on their SaaS. I would love it if GitLab.com could be rock stable like GitHub
> A hobbyist should not need to host their own repo, they should be able to rely on their SaaS. I would love it if GitLab.com could be rock stable like GitHub
As a hobbyist I only commit one small thing a week or so without any issues. I'm curious what stability issues they have for later projects, if you'd care to elucidate?
Can you comment more on why a hobbyist should not need their own repo? If I'm doing SaaS for everything, my monthly costs start to go up.
I've found it is far cheaper, and far (way!) more educational to take an extra box out of the basement and install Ubuntu/GitLab/Node/Java/Apache/Etc.
I have to pay for internet either way, and the electricity cost is nowhere near the cost of having multiple Saas?
Most of the time, it's because of opportunity cost: The time you're spending building a server, learning how to manage repos, setting up redundancy and just trying to get the thing working, you could've spent on whatever product you were trying to produce, and would likely be much further along with if you hadn't done everything the hard way.
That's not to say there isn't educational value, but a common piece of advice I've gotten is "Don't optimize for anything but your life." Or more easily explained: Don't optimize for things you don't need to.
The opportunity cost on the front side is often worth it but the long term benefit on the back side is you aren't dependent on that SaaS, are running stuff you know something about and have a lot of flexibility.
I'm from the old school, I use SaaS/PaaS mostly for stuff I know is painful to do yourself (sometimes file storage, nearly always email) but the rest lives on vanilla boxes configured with ansible (frankly ansible is faster to use once you get your head around it than learning 5 different PaaS setups).
The ansible docs are excellent and walk you through the process, one thing I did (and would suggest) is use vagrant (or similar) with ansible, it has built in support for it and it allows you build/tear-down way faster while you are learning.
I'm personally glad to have done things the hard way,
sure it took some time to learn but learning sysadmin made me a better developer.
To me, setting up a repository, an issue tracker, a wiki etc. was more about learning about a process than learning "how to make it work on the server".
Process as "how to organise the production of writing software" and this is imho extremely important, I reuse what I learned all the time from web app to mobile app to server backend etc.
Simply put, I see a lot of people who fail to deal with software production simply because they just use the tool "a la mode" like Github, but are completely oblivious to the benefits of using semantic versioning, an issue tracker, a wiki for documentation, etc.
When you learn all that by yourself, you can compare different tools and have a feel for what's a "bare minimum", you just know how to manage/organise a project a make it work in production.
Building on the other answers, I think it is more awful for pros. Hobbyists don't have deadlines and spend time on computers because of love, not to pay rent.
That said, you do have a point, and you decide what matters to you as a hobbyist (or whatever you decide to call yourself).
I personally like (and need, most of the time) stuff that "just works", so I totally get your point about optimizing and agree with it.
> A hobbyist should not need to host their own repo, they should be able to rely on their SaaS. I would love it if GitLab.com could be rock stable like GitHub
I completely disagree, here a little story
before 2005 I was hosting my own SVN repos, then came a community "we host your open source project for free" and I moved my sources there
and it closed, so I moved all my repos (they kept growing) to google code
my main reason to move to google code was "its' google they will never close down"
guess what? few years later, google code close down
at that point I decided NERVER EVER AGAIN, I moved all my repos to my own private dedicated server
now I do use Github but as a mirror, they can close down tomorrow I don't care (note: I don't wish them that)
Some people take their repositories very seriously, hobbyist or not, for me it's like backup you only see how important the infrastructure is when the shit hits the fan.
Things like Github, Gitlab, etc. are nice but it's merely a beautiful web UI on top of what is important: the repository.
My point is even if you are an hobbyist you should own and control your repository, if you can host it on a dedicated server, or at home on a spare box, whatever, do it, do own it (the infra), yes because a tarball archive of your repo and a JSON export of your issues is completely useless.
Doesn't every distributed system let you keep your own repo under your control? I have all my projects on github but if github disappeared tomorrow I'd just push my repos to a different service.
We've been using GitLab CE internally in our organization for more than a year. We needed an on-premises solution because of the company's policy. The experience has been great thus far.
On EE, there's nothing that we miss from the EE version, although we might end up going with EE after the team will grow. We also have dedicated dev-ops, otherwise having support for it would sounds good. And the pricing for EE if you go that route is much better than for GitHub Enterprise.
Personally I have mixed feelings about the "open core" model, as many times it's just a marketing stunt. But for now that's not the case with GitLab.
> I still don't know how I feel about GitLab. My initial reaction was that they were an underhanded, cheap knockoff of GitHub. It felt kind of dirty, like they were stealing GitHub's thunder and giving it away for free.
Richard Stallman is the "prophet" of free software. The EE license is not a free software license (and probably isn't an open source one either). The given license doesn't give you any of the four essential freedoms.
> "Right now GitLab.com is really slow and frequently down. This is because of fast growth in 2015. We are working to improve it in the first quarter in 2016. For now please consider downloading GitLab and using it on-premise for a fast experience."
Is this a joke? I mean for people looking for free private Git hosting, there is Bitbucket. This statement is like saying "free, but not really, really." The fact is if I want hosted Git hosting from Gitlab, I cannot reliably get it without paying at least $390 upfront for their EE plan. Too much smokescreen, too less actually on offer.
I did. Some customers of mine use it (free tier if possible) for their private projects. My assesment:
* issue management is better than GitHub's one but for very simple needs (90% of the repositories?) GitHub is enough and BitBucket is needlessly complicated (don't even talk about Jira).
* repository navigation is worse (finding the repositories themselves can be difficult if you land on the wrong page)
* wiki/pages are probably the same
* access control and general management is better
* pull request... I don't know. Our teams are small and normal communication plus git merge are enough.
I use it for personal, small scale repos where i just want to have the repo online and available across machines. Having the free, hosted tier is invaluable to me as a single developer.
That said, I've also used it in a paid, hosted environment supporting a team of 10. Again, our needs weren't overly complex and the integration with team software like Jira and Confluence were great (as can be I suppose, given the complexity of both tools).
I'm actually surprised there isn't more of a discussion around bitbucket and the cost of hosting smaller, private repos. Do most just dislike bitbucket or are you hosting bigger projects with multiple contributors which requires Github / gitlab services?
We use BitBucket extensively at my company for two reasons: Mercurial support and Unlimited private repositories.
The mercurial support is great because of legacy code (I finally have come to admit that Git is superior for most purposes). The unlimited private repositories is great because we make loads of projects. I came from so many companies that would have this giant monolithic tree of tangled dependencies because they would check everything into one project. I fear this with GitHub's pricing model.
I find BitBucket's dashboard useless. It used to be decent but they changed it some years back. BitBucket's security was sort of disturbing as well but I believe they have added 2 factor authentication.
I will say that Atlassian's Jira used to be the best bug tracking but I have found that in the last couple of years it has become a complete bloated pig that is overly complex and slow. The hosted Jira is so awful that we contemplated just using BitBucket for bugs. We eventually switched to Youtrack and are loving it.
Bitbucket allows only 5 contributors for free private repos. Gitlab allows unlimited. That is the major point of distinction, imo. Especially for medium sized projects.
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.
Except that it's unreliable, the website says so. Let me ask again, is there any plan without $390 onboarding provided by Gitlab that gives me following features:
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.
If I have to host myself, why won't I simply host Git? The point of these services is peace of mind. If I'm managing on-prem, it kind of kills the point.
While I dont agree with the GP, from the phrasing its clear they mean that the project would be hosted on Gitlab's servers.
In my opinion its nice to have the ability to host it yourself and it was the primary feature attracting me to GL, followed by it looking user friendly for a few people I am working with who are not shell people, and what finally sold me is they clearly have a team which is focused on making the product better.
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 FOSS.
> 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), but my company prefers on-prem whenever practical for various reasons.
Self-hosted GitLab doesn't fit all the same uses as GitHub (I wouldn't use it for personal projects), but when it does fit it's great to have.
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.
The "crippled community edition vs paid enterprise edition" business model raises red flags. It's not that different from the free crippled demo version or outdated by 2+ major versions freeware model.
Who gets to decide that features are enterprise only ?
How are these enterprise only features: "Hosting static pages straight from GitLab", "git-annex", "git hooks", etc. ?
Get a crippled version that doesn't fit the reasonable expectations or pay for enterprise edition coming with a big bag of features I have no use for just to get the missing features that I can have on github for free (And I'm not a big fan of github)?
As such gitlab community is not very useful to me and does not seem to have a future because its chosen business model goes against its usefulness to people.
I think called the community edition crippled is a stretch. I have a small team (4-5 devs) that has been using the CE for a few years now and we have been more than happy with it for all of our needs.
The EE edition features make a lot of sense for much larger organizations I suppose.
GitLab CE is not crippled in any way, it is used every single day by hundreds of thousands of companies and millions upon millions of developers. It is and has always been our (GitLab, the company) main focus, we only decide to make new features EE-only when we think that they are mostly interesting to companies with 100+ employees. Besides the company's efforts, contributions from the 1000+ community contributors always go into CE, unless the contributor submits it to the EE repository specifically.
Note that our free, hosted GitLab.com runs EE, which means that EE features like GitLab Pages ("Hosting static pages straight from GitLab") are available to everyone.
Just yesterday I ended up implementing my own mirroring of GitHub repositories. GitLab supports this in EE (new in 8.3), but not CE.
That's not a feature that only large enterprises use–I run an open source GitHub organization and wanted to use GitLab as CI. It works! But I needed to reimplement an EE feature to do it.
To be clear, I don't think there is anything sinister about keeping features behind a paid firewall. That is how software developers have paid their rent for decades. I'm just saying that the EE features are not all "mostly interesting to companies with 100+ employees." Several of them are things I needed as a single open-source developer.
I've debated about buying EE to fill in the gaps, but you sell licenses in packs of 10, and I only need 2 :-)
> I run an open source GitHub organization and wanted to use GitLab as CI. It works! But I needed to reimplement an EE feature to do it.
Is there a reason why you didn't use GitLab.com, which runs EE and thus has Repository Mirroring?
> I'm just saying that the EE features are not all "mostly interesting to companies with 100+ employees." Several of them are things I needed as a single open-source developer.
Fair enough, I'm not saying our judgment of what is and what isn't interesting to smaller/single-person teams is perfect. If the general feedback of the community is that a certain piece of functionality belongs in CE rather than EE, we will consider bringing it to CE. We have done this in the past.
> Is there a reason why you didn't use GitLab.com, which runs EE and thus has Repository Mirroring?
1. My hosting is way more reliable than yours :-)
2. I need to host the CI runners myself anyway, because you don't have the right config
3. I already have a private GitLab install, so it's no extra trouble
4. My repository mirroring is quite a lot better than yours, as it's instant, not hourly
5. I prefer to have a commercial relationship with important tools. You seem like nice people, let's see what happens when you get acquired. As long as you can't be bothered to sell to 2-person teams, I'll just run CE and have my commercial relationship with AWS instead.
> 4. My repository mirroring is quite a lot better than yours, as it's instant, not hourly
Heh, care to share? :) Maybe we can take some pointers from your implementation. How does your repository mirroring know that the upstream repo was updated? Do you use webhooks on GitHub? That would actually be pretty easy to implement, an `update_mirror` GitLab API endpoint that GitHub could call to, hmm...
> 5. I prefer to have a commercial relationship with important tools. You seem like nice people, let's see what happens when you get acquired.
What are you afraid of?
> As long as you can't be bothered to sell to 2-person teams, I'll just run CE and have my commercial relationship with AWS instead.
Mostly, that you'll get bought by the likes of Oracle. In spite of my quibbles about CE features, I think you're doing a (mostly) fine job of CE right now. But your acquirer will see CE as a cost center (there's no revenue) and will want to "streamline" by focusing on enterprise (where your balance sheet is). GitLab.com will also look like a cost center, and will either shut down, turn into a datamining opportunity, or go through the bad PR of no longer being free. I fully anticipate, in 5-10 years time, that I will be running a CE fork to get out from under your acquirer, just like StarOffice, MySQL, Hudson, etc.
Contrast with GitHub, who makes a silly amount of money from people like me. Their acquirer would be mad to screw up a winning formula.
The good news is, GitLab is such a good product that I still hugely prefer it even after "pricing in" the risk (cough, certainty) that my days are numbered. It is an amazing tool, it really shows that you care about it. For now.
All right, I see where you're coming from. I think any eventual GitLab acquirer would be mad to screw up _our_ winning open core formula, but I'm not in a position to tell the future or make any promises.
I've asked our CEO Sid (you know, the "GitLab CEO here" guy) to chime in.
> I think any eventual GitLab acquirer would be mad to screw up _our_ winning open core formula
Understand, I want to believe. I want to live in a world where open core works at VC scale and over long timeframes. I'd love to run all my own projects that way, if it was possible. And who knows, maybe you will be the people to do it where everybody else failed.
It's just the available evidence suggests I don't live in that world. In my world, you have to pay money for things if you want them to last. I'd like to pay you money, but you don't want it, and that's weird.
Look at it from my POV. GitLab isn't "just" another tool for me, it's my homepage. I'm in there hours every day. I trust it to store my life's work. That's amazing! People literally kill to get that deeply embedded into their customers lives. But it's also a huge responsibility. You and I are in the honeymoon period right now, but when times get tough and we have 3 kids and a mortgage, it's going to get real.
You may not be in a position to speculate that far out, but I have to. I'm still going to need this product in five years. You might not need me.
We can't promise we'll never be acquired but we when we raised financing we tried to ensure that we're as much in control of our destiny as you can be as a VC founded start up. For example last month we were cash flow neutral.
GitLab CE is MIT licensed and will not go away in case we get acquired. Some companies (including Oracle themselves) are using GitLab CE with thousands of users (they rebranded it as Orahub, don't ask).
Honest question, did you ever consider making self-hosted GitLab EE free under a GPL-like license, but only for installations that only host open source and are reachable from the internet?
You might even get the community to develop EE features for you to sell :)
I don't think that limiting it to only-open-source is compatible with the GPL license. But in the HN thread I did make an offer for free EE licenses for open source projects https://news.ycombinator.com/item?id=10924406
There is nothing crippled about GitLab CE. There are a few features that are clearly useful to large enterprise users, and if you're using GitLab with 50+ employees I'm sure $39 per year year per seat isn't going to break the bank.
We've been using GitLab CE for a while internally and it's fantastic. Don't dismiss it because of some narrow-minded ideology.
I chose Gitlab for my former company over GitHub Enterprise because we wanted an on-prem solution, and it worked well enough for ~200 folk. We did have to tweak (and occasionally break) a few things, since quite a few people suffered from NIH syndrome and wanted things done "the right way".
In general, I liked it, but it always irked me that its Ruby underpinnings made it hard to upgrade/migrate stuff (we basically just swapped LXC containers at one point, not sure how it was handled during the last upgrade). If anyone ever manages to do a credible alternative that does _not_ use Ruby in any way but keeps the overall GitHub-like workflow, a lot of operations folks will switch _instantly_.
Also, like some commenters already pointed out, the CE edition was ridiculously limited in some regards - we mostly skipped the bits we didn't like and did product-level ticketing outside it (using Trac), with Gitlab issues used only for "techie" stuff, tracking fixes, etc.
But today I'd probably just sign us all up for GitHub and be done with it, or fire up a VM image from some marketplace - there's hardly any point in maintaining our own infrastructure or doing a lot of customization.
1. For starters (besides other internal stuff), we were the guys who needed Shibboleth support. You might recall there were a few pull requests from a colleague of mine regarding that :)
2. No, we had to tweak the source, so I don't think the packages were useful.
3. Static pages, hooks and merge approvals would be right at the top of my list. Audits would be nice to have, but we figured out how to do that on our own.
Also, issue handling needs some improvement. We just couldn't map our Trac workflow to it - but that's a fairly longer story, and it would probably be the same if we used GitHub.
GitHub Enterprise was essentially a closed VM that did not allow us to do the sort of customisation we needed - nor, most crucially, mount the git repos from our enterprise SAN.
Gitlab allowed us to do that without any hassle, even running inside an LXC container.
Nowadays, the omnibus package makes gitlab pretty easy to maintain.
I had to do an upgrade from Gitlab 6.9 (source-based on ubuntu 12.04) to 8.3 (omnibus rpm on rhel7, managed via puppet) recently, and it was surprisingly smooth.
The package-based installer bundles all the needed software, which is quite okay for software like gitlab that often depends on specific versions of auxiliary software. It uses a built-in chef to configure its components.
I performed the upgrade in two steps, first to 7.14 (on the source-based install), then did a backup/restore to the new server with omnibus and upgraded it to 8.3.3 with yum.
Gitlab migrated the database mostly correctly (there were some issues with the LDAP provider; some users had the wrong provider in the database, but that was easy to fix manually. I'm not sure what caused it) which was quite a surprise considering I went up 2 major versions in two steps. Even upgrading the source-based installation went very smoothly even though it had to download a couple dozen ruby gems from the internet.
The upgrade also affected CI functionality for one of our users but I think that was because it relied on pre 8.0 non-builtin CI, and simply needed reconfiguration for the new system.
Afterwards, a point-release upgrade took a whopping 5 minutes (most of which was downloading and extracting the new RPM).
Because the thread has turned into a "why I like/dislike GitLab over GitHub", I'll say one thing that keeps sending me back to GitHub is the neat-o desktop client.
I use a command line for everything else in life; but with Git I'm hopeless.
I currently do this for the basics, and drop down to git at the shell for anything more complex than the one or two things GitHub's client does well. It's a decent trade off in my opinion.
Please improve your mobile UI - phones have lesser horizontal space than vertical. You have put a cool looking sidebar on the left side which takes up a lot of space causing text layout to be funny on my 5.2 inch LG G2.
You should be able to collapse the left sidebar. But we are the mobile UI has deteriorated in the last few releases and we plan to look into it in the coming months. If you want to get paid to contribute, we're hiring front-end engineers https://about.gitlab.com/jobs/
Before you think of switching to GitLab, look at their status Twitter account over the past few months. They've had a lot of down times. They run on Microsoft Azure.
Reading their Twitter status messages. Microsoft sponsored Azure for Gitlab. Between Oct and Dec they were on Azure, and they had major issues with the Azure platform, pretty unreliable for their use case. Gitlab switched to IBM Softlayer because of that experience. Read yourself: https://twitter.com/gitlabstatus and https://gitlab.com/gitlab-com/operations/issues/17
It seems they have switched back to Azure now. In my own (very limited and small-scale) experience, Azure is pretty solid. Although some of the APIs seemed a bit unnecessarily convoluted compared to AWS (can't recall any specific instance).
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
If GitLab plays their cards right, they can take the market from github. That, in my book, will be good because unlike github, we can all contribute to making GitLab better.
The only question left is if your servers are powerful enough to run gitlab. Maybe I'll sacrifice a goat for some new server hardware and 256GB of ram.
By the way, I don't want to troll you, but at my company we use Gitlab 6 self hosted version and I wasn't able to do a simple git push origin master
the repo I held in my machine was barely 5MB and still remote server closed connection HTTP 500
I solved it by increasing the POST buffer.
I never had this issue with github, maybe you can check why it was an issue with gitlab? it might help to advance your product!
GitLab introduced a new web server (gitlab-workhorse) in 8.0 that's better at handling large HTTP requests. I would suggest upgrading (not just for that reason, there have been tons of improvements and security updates).
I don't think the fact that GitLab is free for basic users is very discoverable from the site. You've got the "features" tab, which leads to what seems to be the option of downloading a community edition, which makes it look like GitLab is only offering the code itself but not hosting from their, and the enterprise edition for some licensing fee (I suppose). Then you've got "sign in", but no "sign up", which leads me to ask "but then how do I sign up", which most naturally (for me) leads me to the "pricing" tab. Now this page only shows "trial" and the different priced tiers.
But if I press "sign in", I am able to sign up, with no notice about it being just a limited (45 day) trial. So so far I'm assuming that this is a perpetually free account, though I'm not completely sure yet...
1. Community edition
2. Enterprise edition
3. On our server
The 3rd option has this text: Free hosting for private repos? Sign up to get unlimited repos and collaborators.
Clicking on Sign up takes me to https://gitlab.com/users/sign_in which has clear options to sign in or sign up. It also has the text: GitLab.com offers free unlimited (private) repositories and unlimited collaborators, please sign up or in on the right.
In lesser words, it seems pretty clear-cut to me. They offer unlimited free hosting for your repos. I did not see any trial period anywhere. Maybe you went to the Enterprise option?
Hmm, the front page (https://about.gitlab.com/) lists "GitLab.com — On Our Server — Free hosting for private repos? Sign up to get unlimited repos and collaborators. — Sign Up", but I get that it's a bit confusing that the features and pricing pages don't mention anything about it.
To clear things up: GitLab.com is completely free, with unlimited projects and collaborators. GitLab CE is open source and completely free. GitLab EE costs money and has a 45-day trial.
I definitely think there's a discoverability issue there.
1. The Hosted CTA is the right-most one. People don't read that one. Eyes naturally go to the first CTA, and then compare it to the 2nd one. Based on the first 2, I expect the 3rd one to be another downloadable package, not a hosted option, so I don't read it.
2. The top nav-link is "gitlab.com" not "hosted service". If I don't know that gitlab.com is a git hosting service, I'll never look there.
3. As mentioned, features + pricing don't mention gitlab.com, so once you get off the front page, you lose any hints of a hosted option unless you know what the "gitlab.com" link is for.
4. The first headline that my eyes go to below the fold is:
Self-hosted, scalable and updated monthly
That implies to me that "gitlab" is (exclusively) a self-hosted product, and isn't available as a SaaS option.
Yes, it does also say "Or use our free SaaS GitLab.com" but you can't really expect people to read the text immediately below a headline that (effectively) says "not what you're looking for"
Right now, since you're advising people to go self-hosted rather than gitlab.com, that might all be working in your favour. But when you get the performance + reliability of gitlab.com sorted out, I'd strongly advise you to make the SaaS option a lot clearer.
(I realise that I could submit a patch to index.html, but I don't think my 10 minutes of hacking is going to get you to the best outcome)
Perhaps if they had the same uptime, page load speed and UX as Github, I would consider it. Unfortunately we tried it for a week at work and none of us could figure out our way around it (when it was working).
I'm sorry that GitLab.com was unavailable an slow. As mentioned on https://about.gitlab.com/gitlab-com/ we're working on that. Have you considered self-hosting it?
This attempt by the Gitlab folks to ride the Github dissatisfaction wave seems a little low-brow. Why respond to a letter that's not addressed to you? I would have preferred them to simply post an honest "Why you should migrate from Github to Gitlab" article. The tone just seems a little devious to me.
By the way, we're using self-hosted Gitlab at work and we love it. This isn't a knock against the actual product. In fact, I think Gitlab has improved tremendously in the last 18 months. I just wish they would be a little more up-front about their marketing efforts.
> This attempt by the Gitlab folks to ride the Github dissatisfaction
> wave seems a little low-brow.
There's a github dissatisfaction wave?
Anyway, opening sentence of gitlab's open letter: "The letter of GitHub’s open source community is clearly not addressed to us, but we’re thinking a lot about the issues that were mentioned in it."
Does that cover your concerns?
I think if github was the free software entity, and gitlab had no free software edition available, then the tone would be, as you suggest, totally inappropriate. However given the arrangement is the other way around, it seems quite reasonable they would hop onto this issue at this time, especially given the very clear caveat quoted above.
"Wave" might be too strong a word, but I've seen three or four posts on HN in the last few days that were pretty critical of Github's closed source nature and insufficient transparency.
I'm not sure why offering a free software edition somehow gives you a pass. Both Github and Gitlab are commercial entities as far as I know.
Anyway, my concern wasn't a big deal, I was just a bit taken aback at the opportunism. In retrospect, I think my reaction was a bit overblown.
Fair enough. I feel like there's been stories / sentiment along this line for a while, though apart from Microsoft's ChakraCore announcement last week (?), the only two specific stories I recall from last year were about github's valuation (US$2B) and when they threatened to remove someone's repository because it contained the string 'retard'.
You're right that both github and gitlab are commercial endeavours - obviously very much in the same space - so I'd expect them both to pop up in any discussion about bug & feature trackers, community involvement, etc - especially if there's the potential to improve their business.
On the other side of the coin, I'm curious why Github seems to often get a pass by the free software community.
> Why respond to a letter that's not addressed to you? I would have preferred them to simply post an honest "Why you should migrate from Github to Gitlab" article.
That's basically what they did. They said "hey, you have these issues with GitHub, we're covering them, AND we listen to the community".
I think it's great that they responded to it, since it proves they actually listen and care about what their audience thinks.
> This attempt by the Gitlab folks to ride the Github dissatisfaction wave seems a little low-brow.
I can hardly imagine a better outcome. Now both GitHub and the developers have a choice to make; GitHub can either ignore the complaints or take them into account, and people can either continue using GitHub or start using GitLab (or something else). Nothing better than informing people in a kind, respectful manner.
Since they have employees and apparently are an ongoing business concern I would be worried if they didn't try to get their name in the conversation. If they let this huge discussion go by the wayside silently then they would be incompetent business people.
Yes, that's sort of the point I'm (badly) trying to get across. I think the product speaks for itself. That said, I may have misinterpreted the tone of the article.
I think, that GitLab staff wrote respectfully, in an open manner.
> I think Gitlab has improved tremendously in the last 18 months.
I agree, IMO it's already better then github - I know people will disagree on that, but I find the UI way better - Easier to find things and navigate for someone who doesn't work in github very often (milestones for instance).
As a quite disappointed user of Gitlab (due to issues raised here, e,g, CE vs EE and the Ruby infrastructure), has anyone had experience with both? I understand that Phabricator is a more "complete" solution, but how do they compare in the core features that they both share?
Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.
> I understand that Phabricator is a more "complete" solution, but how do they compare in the core features that they both share?
I think GitHub is prettier, but having tasks separate from repos and having tasks be as sophisticated as they are in Phabricator and having such a better pull requests system, it doesn't matter? GitHub has to dumb down the user interface on their product to appeal to the least common denominator and maintain their growth. Phabricator is for projects where people care enough about their projects to learn the UI so they can get things done.
> Also, do they pride themselves for writing this in PHP?
As a user I doubt you're going to find your self caring about how it's written.
As a user of a self-hosted web service, how it's written affects details about the pain of deployment and administration. How it's written also affects whether it has satisfactory performance and how many nasty security problems are waiting to be discovered.
Not everyone can afford to be completely blase about their source control system going down or getting defaced.
PHP apps are a hell of a lot easier to keep up-to-date than the unholy hell of Rails apps, especially when you discover developers have started locking dependencies to old gems with known security issues.
We've been using Phabricator for a few months, coming from private repos on Github.com. We initially liked it because it "ticked all the boxes" for the features that we needed from a source code and issue tracker. However, we ran into major issues along the way, basically because some of the concepts in Phabricator aren't compatible with our workflow. We decided to switch to Github Enterprise and haven't looked back since.
Some of the issues we had with Phabricator:
1. Phabricator is actually a suite of different applications that do specific things (e.g. source code hosting, issue tracking, project management, ...). Although Phabricator ticked all our feature boxes, some of the components it ships with are very immature and/or don't get a lot of attention from the development team.
2. For some reason the platform as a whole feels like a CRUD layer on top of a data model. The UI and various workflows in the applications are very tightly coupled with the underlying data model. I guess that makes it easy to develop and maintain the various core applications of Phabricator, but it doesn't make for a very user-friendly or usable product.
3. We have ~150 internal repositories, we actively work on ~40 of them at any given time. The source code application doesn't seem intended for that many repositories (e.g. navigating to a specific repository is non-trivial)
4. Phabricator has a fundamentally different approach to "pull requests". It works really nice, but only if you commit to using the Phabricator Way Of Doing Things. However, our team has been working on Github.com for years, and we're so used to the Github-workflow that we couldn't get used to the Phabricator workflow.
In the end Phabricator just wasn't the right tool for us. It definitely has some attractive properties: it's easy to install and upgrade, the command line tools are solid and provide all functionality you need, and it performs extremely well even on a small EC2 instance.
> 1. Phabricator is actually a suite of different applications that do specific things (e.g. source code hosting, issue tracking, project management, ...). Although Phabricator ticked all our feature boxes, some of the components it ships with are very immature and/or don't get a lot of attention from the development team.
The features which aren't explicitly marked "experimental" work very, very well in my experience. Especially the code review part, which I find more pleasant to use than Gerrit.
> 2. For some reason the platform as a whole feels like a CRUD layer on top of a data model. The UI and various workflows in the applications are very tightly coupled with the underlying data model. I guess that makes it easy to develop and maintain the various core applications of Phabricator, but it doesn't make for a very user-friendly or usable product.
Have you got some examples? They're hiding the database pretty well IMO, and we haven't had many usability complaints that weren't about minor issues. Many of the experimental features are cumbersome to use though and we've turned off some of them again to avoid confusion.
> 3. We have ~150 internal repositories, we actively work on ~40 of them at any given time. The source code application doesn't seem intended for that many repositories (e.g. navigating to a specific repository is non-trivial)
Have you raised an issue about this? They're very responsive to issues encountered in real-world use and usually decide about feature requests by user demand. I do know that they're working on improving this - the "callsigns" will become optional, for example.
> 4. Phabricator has a fundamentally different approach to "pull requests". It works really nice, but only if you commit to using the Phabricator Way Of Doing Things. However, our team has been working on Github.com for years, and we're so used to the Github-workflow that we couldn't get used to the Phabricator workflow.
Their way of doing (or actually, not doing) pull requests is the most important feature of Phabricator. Their approach scales much better than the traditional style and is - in my opinion - the most important reason to choose Phabricator over Github-style tools. This might not matter for small projects, but in a company, it sure does.
Hi, sorry for my late reply, apparently I'm not notified of responses to comments :-).
1. That's true; the non-experimental parts of the suite are mature and work really well.
2. This was most apparent in experimental features like Harbourmaster/Drydock, where you need a lot of clicking around to configure a basic build setup. Granted, that didn't apply as much to the core applications, but we didn't find those very user friendly too. The task detail screen in Maniphest, for example, is super-cluttered with all kinds of labels, links, and text in the main panel of that screen. Also, the fluid layout in Maniphest makes it hard to read task descriptions/comments because lines of text get very long.
3. No, we didn't, because we were going to switch away to Github Enterprise anyway. You're right about responsiveness of the team, we noticed that too, and that's really nice.
4. Exactly, code review is how Phabricator started and I can definitely see merits in their approach. However, we aren't interested in changing the core workflow of 15 engineers just because it's theoretically a better way of doing code review. We're getting actual work done just fine with Github's PR system, despite the flaws it has, and that was one of the main motivations to go back to Github (Enterprise, in this case).
Like I said earlier: I think Phabricator is actually a very nice tool and I can see how it works really well for large teams that are willing to commit to the code review style. It just wasn't the right tool for us :-).
> Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.
I'd prefer it to be written in something else, too, but - the Phacility team are ex-Facebook developers. If anyone knows how to use PHP, it's them. They built their own, extensive web application framework on top of it (which is a remarkable achievement for itself). Phabricator is one of those rare examples that you can, in fact, write excellent code in PHP.
I'm primarily a Ruby developer, but my current gig has me working exclusively in PHP (and worse yet, Wordpress). PHP as a language is actually pretty stellar these days. There are things about it that I dislike, but there has been a lot of recent work put in to improving the language. I'm always finding nice features.
Really the place that PHP is lacking is on the tooling/ops side of the projects built on top of it. A lot of what I have to work with still seems to be 15 years old. That said, it's getting better and other peoples' preferred tools have their share of problems as well.
I started looking into GitLab and Phabricator around August/September 2014 for my company. My criteria was primarily based around something to assist with code review. Ultimately I went with Phabricator for several reasons:
1. Supports Mercurial - our repositories are currently in mercurial, and using any other tool would require switching to git (which we seriously considered while looking at tools).
2. Simple to maintain - if you have experience setting up other web applications based around LAMP, this is essentially very similar. The web interface even indicates setup issues to admins, from things which can cause issues to performance configurations in things such as MySQL and PHP.
3. The code review interface was more intuitive for myself and other engineers. From the command-line tool (Arcanist) to how it's conveyed to the user in the web interface. It did take a little time to fully comprehend and implement the process for using, but since implementing in Feb. of last year, after around 4 months we had near 100% adoption by the engineering department. The GitLab/GitHub interfaces I've found to not be organized intuitively -- the lifetime of an issue/changes seems (seemed?) more social-based and intermized where in Phabricator an Issue/Task is almost separate from the changes which can go into it, though they reference eachother easily.
>Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.
I had the same reaction at first (thought I wouldn't say it's pride?). In fact the first time I looked at Phabricator (~2012) I totally dismissed it for three reasons:
1. Written in PHP
2. Mentions pokemon on the front page
3. Marketed as "collection of open source web applications"
These led me to believe that it was at most some PHP glue some students hacked together to get different unrelated applications to play together. This conclusion is entirely wrong. I've since changed my mind about PHP - biased from earlier experiences there's no reason to think a reliable/stable application couldn't be built on it. Phabricator (I believe) started as an internal application at Facebook which has since become its own company. The code is very well organized (I've contributed some small changes), and there are some very bright people working on the project - I get the vibe that they genuinely want to solve the right problems rather than checking features off a list. There are very few dependencies on other libraries unless you specifically decide to enable extra features, and even then there's some support/documentation there to assist. Despite the light-hearted humor (see pokemon) that is a staple of the software (unless you enabled serious-business mode), the project is designed and developed by highly capable, quality professionals.
I couldn't have been happier going with Phabricator over GitLab.
A note - the Phabricator core team have been reticent in merging changes or features that they don't themselves depend on upstream. If you need anything that isn't offered out of the box or on the roadmap, be prepared to maintain your own fork of Phabricator indefinitely.
Phabricator is super easy to maintain. The out-of-the-box experience is better than any complete solution I've tried, including gitlab.
That being said, just like any other fairly complete solution, it's quite opinionated about the right way to do things, and it's very different from github or gitlab. In particular, since it is not tied to git, it duplicates some of git's functionality in its own tools. In many ways I find those tools to be better than what git uses (arcanist just seems more well thought-out from a UI perspective), but it is a learning curve.
If you are happy with svn or hg, and don't want to have to switch to git, Phabricator is a no-brainer. If your team is a bunch of super-advanced git users, they may not like having to learn a different way of doing things.
We had a go at Phabricator for code review. Suddenly, there were two opposing camps - those who hated it utterly and those who loved it and wanted to tweak the heck out of it.
Fortunately (for my team at the time, which was very resource constrained) those who hated it eventually won, but I, being kind of on the fence regarding it (wasn't keen on the UX, but liked the features), sort of wondered what would happen if someone improved the UX beyond the tipping point.
Gitlab might have the resources to properly support multiple vcs' - but even though I personally prefer mercurial (ui, reasonable large-file support) - I'm not sure it would be a good idea. Trac (trac.edgewall.org) did a lot of feature-experimentation -- and I think one take-away is that being an effective workflow support tool and supporting (even subtly) different back-ends with accompanying different best-practices/patterns (eg: git sub modules) is hard.
There's no real limitations on making the two VC system compatible, that's why RhodeCode has same functionality for both Git and Mercurial, without making tradeoffs, that's why systems like hg-git could also work out quite well.
324 comments
[ 360 ms ] story [ 5991 ms ] threadScreenshot - https://twitter.com/gitlab/status/688103614556995584
udaiso03: https://archive.is/jZFbR NSFW!
bamwar10: https://archive.is/HeWvt
opmania35: https://archive.is/jNEr2 NSFW!
https://gitlab.com/gitlab-org/gitlab-ce/issues/8938
I have never used GitLab myself, but some of the features mentioned in the article (like a true voting system) is something I've really longed for. Might have to reconsider trying out GitLab more.
One issue that was raised several times was the ability to not create merge commits. In GitLab you can, as an alternative to the merge commits, use fast-forward merges or have merge requests be automatically rebased.
The main thing keeping me from actually doing it is the network effect... and this:
Disadvantages
Right now GitLab.com is really slow and frequently down. This is because of fast growth in 2015.
At GitLab we are honest about issues, and transparent about what we're working on. HTH!
Or am I missing something? Other than something like usability, perhaps...
[1] I'm not actually quite sure if there is a specific command for that format. Though it should be easy enough to have a third party solution that uses a format through email.
For VLC and all related VideoLAN projects, we're moving to our own instance of GitLab hosted on our infrastructure.
And to be honest, it's quite good, but a few stuffs are ridiculously limited, to the point that some people in the community are resisting the change.
The first part is the groups and subgroups: it seems incredibly difficult to give sub-groups access to repos (like a team for iOS, one for Android, one for libVLC... but all are under the "videolan/" group). It seems there is a way with the EE, but not in the CE; and the current idea for the CE is to have sub-projects, which is not good, because it will make our URLs way more complex than needed.
The second part is the bugtracker/issues tracker. We use trac for VLC, and we want to leave it for something better; but gitlab issues is way too limited, even when using the templates. Especially, it seems to be impossible to add custom searchable fields (like "platforms", "priority" or "modules") which are very very useful to do queries. Also, there is no way to do custom queries and store them ("I want all the bugs for Windows, which are related to the interface modules").
If I remember correctly, this second part was also a complaint in the open letter to github.
Finally, it's not really related, since it's more a feature request, but we'd love to allow external people to fork our repos, but not create completely new ones (or have them validated) because we don't want to host any projects under the sun (there is github and gitlab for that). So far, you either allow both features or none of them.
PS: can we have custom landing pages and custom logo in the CE version? :D :D
Isn't this use-case covered by Gitlab's issue labels?
We want for every bug, that a few custom fields are always defined, to do a partition of the bugs, and to be able to query on those. Moreover, to change the priority or the platform, it's quite complex to do and will break often. Many bugs won't have it filled, for example. Labels do not guarantee that consistency.
As you can see, it's already what people want in the github open letter.
Maybe having some set of mandatory labels? I.e. at least one label from platform list, at least one label from priority list, etc...
[0] https://github.com/rust-lang/rust/labels
[1] https://github.com/rust-lang/rust/issues/5016
type-label
So we might have issues tagged "p-med b-confirmed t-group1"Once there is a method to the madness, it's not bad, and it's more flexible on Gitlab's part I'm sure, to have people tag instead of supporting custom drop-down attributes.
http://trac.edgewall.org/wiki/TracReports
http://trac.edgewall.org/wiki/TracQuery
http://trac.edgewall.org/ticket/1735
Add in:
http://trac.edgewall.org/wiki/TracTicketsCustomFields
And there's a lot of things available before adding custom plugins.
I'd be interested to hear what limits vlc hit in trac (and why they'd rather move than improve trac. Nothing wrong with that - but I confess I have a soft spot for trac and the team's ethos of "try it as a plugin before making it a core feature").
Also curious if anyone know what, if anything happened with the Apache Bloodhound fork/distribution?
http://bloodhound.apache.org/
I always hoped it held the promise of being a simple to install, opinionated trac for multiple (lean?) projects. But as far as I can tell it was pretty much abandoned.
While part of it might be rails-angst and fear of precious stones - I always felt gitlab was a bit of a heavy hammer in terms of install/dependencies/cloc for "just" project management.
In practice the bundled distribution alleviates that - but I still feel taking the "best of trac" and writing a new system a little more opinionated (and probably with a clearer data model) would be worthwhile. Just another project on the todo-heap :)
On a technical level that seems an impossible distinction to make. Someone wanting to host a new project could just fork yours, then make a a commit that deletes everything currently in there, then start their new project.
Having a fork that delete everything and start a new projet is easy to detect and label as spam. (there will always be abuses, but it's okay as long as you can mitigate/moderate)
Sure, but at least it would be clear what is 'allowed'.
We're planning to add cross-server merge requests in the future, which would make it that you don't have to host the forks yourself [0].
[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/4013
redmine, gitlab, bitbucket, github are what I am using for various things.
I wonder if this could be solved by making it really easy to fork your repos, but when that happens the fork ends up (with tight integration) back on the/a public GitLab instance.
1. Our EE version has the function share project with other groups http://doc.gitlab.com/ee/workflow/share_projects_with_other_... If this is essential for you we'll give you a free lifetime license for GitLab EE.
2. You can add custom labels on issues and the searches can be stored in urls that you can bookmark and use in links. You might have considered this already and need more functionality. Maybe it is best to discuss this in an issue so I created https://gitlab.com/gitlab-org/gitlab-ce/issues/10712 Please add there what you need in addition to the labels functionality. We addressed the long list of items raised in the original Google Doc letter below the signatures in https://gitlab.com/gitlab-org/gitlab-ce/issues/8938#improvem... The first item under improvements details our reponse to that question.
3. In GitLab you can give each user a fixed number of new projects. That should prevent people from storing a excessive amount of repo's. But feel free to make a feature request to limit people to only forks. As other replies have indicated that still allows people to work around it but at least the intention will be clear.
4. A custom landing page and logo is an EE feature http://doc.gitlab.com/ee/customization/branded_login_page.ht... We think this is more relevant for larger organizations so we're comfortable for having it as EE only at the moment. As mentioned under 1. we're open to offering you (and other open source projects considering self-hosting) a lifetime EE license.
I'll be in the comments today (just woke up in SF). You and any other open source project can always reach me at sytse@ company domain to get assistance or claim the EE license.
The whole idea of VideoLAN infrastructure migration from gitweb/trac/etc to gitlab and not to github was to use and promote free and open-source software.
Using closed-source software there is out of question, really.
[1] I.e. a licensing model based on GPL and selling services that Red Hat uses for RHEL, instead of a licensing model like they, and a minority of the "open source" companies, use.
Anyway, maybe you could be a bit more specific about the problem you see with our model, I would love to get specific. Also see https://about.gitlab.com/about/#stewardship
BTW I presume RedHat choose a GPL license for RHEL because they didn't have a choice due to the GPL license on Linux.
We tried charging only for support but now that we have the Omnibus packages it is rare for users to need support (and we like it that way).
"This software and associated documentation files (the "Software") may only be used if you (and any entity that you represent) have agreed to, and are in compliance with, the GitLab Subscription Terms of Service, available at https://about.gitlab.com/terms/#subscription (the “EE Terms”), and otherwise have a valid GitLab Enterprise Edition subscription for the correct number of user seats."
1. Thanks, but see above :)
2. As I said, custom labels are way too limited, as people on the open-letter-to-github said, so I will comment on the issue.
3. Will do.
4. same as 1 :) But thanks a lot.
I will contact you :)
With MIT license, many sites probably just implement the branding changes etc in the CE product on their own.
While I get the sentiment, I don't think this helps. If you want to help the Open Source community, give us what we need in the form of open source. If I don't care about vendor lock-in I can go ahead and use GitHub. GitLab counts because its open source, and its open source version is the only thing the open source community should care about.
I have seen the feature of being able to customize the login screen come up in discussions about gitlab come up so many times, in so many places, and I usually see it met with "EE feature" or a community member saying something like "gitlab is open source just change the files on your server".
This seems like such a basic thing for an open source software like gitlab to just provide out of the box, i can't believe it isn't listed under your " ... an EE feature that is would come up frequently in these conversations ... " that you "would not hesitate to open source". Especially since at least several of the people you're replying to in this thread have mentioned it specifically.
Is gitlab really making enough income from enterprises who decide that this is the killer feature that they need to pay for EE to get?
It seems like a simple matter of moving the gitlab branding on the login page to the footer with a "powered by gitlab" type of thing and a logo.
Please don't take my meaning as a hateful rant, I love gitlab and personally manage 2 seperate deployments of gitlab CE, but i am not ashamed of saying that this is something of a frusteration to me, and I have a hard time taking this
>If there is an EE feature that is would come up frequently in these conversations we would not hesitate to open source it
statement seriously in light of how many times I have seen this seemingly harmless feature shot down for essentially no real reason.
I've made https://gitlab.com/gitlab-org/gitlab-ce/issues/11489 to discuss.
So thanks for the offer, but no thanks.
If you have Java
just type download gitbucket.war
> java -jar gitbucket.war
I'm a Gitlab users for a few years now, personally I like it much more than Github, one of the reason is that I fear that Github contains too many projects and gains too much control over OSS, I also dislike their CoS.
Good luck Gitlab!
I don't understand this fear. All repositories on GitHub can be hosted elsewhere. Moving metadata (e.g. issues, milestones, PRs, etc.) is more difficult but mostly possible.
Disclaimer: I like that GitHub is the "central" place for OSS, it makes my life much easier. I know how to use the product very well and it's convenient having almost every project that interests me available there.
I'm curious as to how people tend to go about doing this. Any recommendations?
Monopoly. Github enforces their CoC which has nothing do to with good coding practices or technological progress, they ban repositories and people based on their views expressed in comments.
So now it even feels like they're doing Git hosting the right way, making the core software open source, and charging for enterprise features.
On the other hand, I would have probably never paid for GitHub if they followed this model. So I don't think GitHub would have been as successful.
I feel its community edition is up to par with github in most aspects and it a was a change towards the better from our previous svn based solution (Redmine)
It seems just about everything is being re-written in Go these days...
You could have said that without cheapening the level of discourse.
If you're not you just seem like someone who came to the NodeJS Party late and didn't understand Go is C for gigantic codebases using parallelism. :D
That said, it's probably not a good fit for most businesses at this point. It's relatively new, and mostly maintained by a single developer, who spent the last summer on vacation.
He's very active when he's around, and almost always working on improving Gogs, but there's a lot of people with features requests (the issue that's always getting comments today is for opening pull requests across branches within a single repository -- i.e. not forking.)
https://confluence.atlassian.com/bitbucket/enable-an-issue-t...
[1] http://gitlab.com
Believe me, we would too and we are sorry about the current state of GitLab.com. We are working on improving performance in Q1 2016: https://gitlab.com/gitlab-com/operations/issues
That's not to say there isn't educational value, but a common piece of advice I've gotten is "Don't optimize for anything but your life." Or more easily explained: Don't optimize for things you don't need to.
I'm from the old school, I use SaaS/PaaS mostly for stuff I know is painful to do yourself (sometimes file storage, nearly always email) but the rest lives on vanilla boxes configured with ansible (frankly ansible is faster to use once you get your head around it than learning 5 different PaaS setups).
http://www.ansible.com/get-started
I'm personally glad to have done things the hard way, sure it took some time to learn but learning sysadmin made me a better developer.
To me, setting up a repository, an issue tracker, a wiki etc. was more about learning about a process than learning "how to make it work on the server".
Process as "how to organise the production of writing software" and this is imho extremely important, I reuse what I learned all the time from web app to mobile app to server backend etc.
Simply put, I see a lot of people who fail to deal with software production simply because they just use the tool "a la mode" like Github, but are completely oblivious to the benefits of using semantic versioning, an issue tracker, a wiki for documentation, etc.
When you learn all that by yourself, you can compare different tools and have a feel for what's a "bare minimum", you just know how to manage/organise a project a make it work in production.
That said, you do have a point, and you decide what matters to you as a hobbyist (or whatever you decide to call yourself).
I personally like (and need, most of the time) stuff that "just works", so I totally get your point about optimizing and agree with it.
Maintaining the 10x SaaS services you use in a similar vein suddenly starts eating up close to whole days.
I completely disagree, here a little story
before 2005 I was hosting my own SVN repos, then came a community "we host your open source project for free" and I moved my sources there
and it closed, so I moved all my repos (they kept growing) to google code
my main reason to move to google code was "its' google they will never close down"
guess what? few years later, google code close down
at that point I decided NERVER EVER AGAIN, I moved all my repos to my own private dedicated server
now I do use Github but as a mirror, they can close down tomorrow I don't care (note: I don't wish them that)
Some people take their repositories very seriously, hobbyist or not, for me it's like backup you only see how important the infrastructure is when the shit hits the fan.
Things like Github, Gitlab, etc. are nice but it's merely a beautiful web UI on top of what is important: the repository.
My point is even if you are an hobbyist you should own and control your repository, if you can host it on a dedicated server, or at home on a spare box, whatever, do it, do own it (the infra), yes because a tarball archive of your repo and a JSON export of your issues is completely useless.
Doesn't every distributed system let you keep your own repo under your control? I have all my projects on github but if github disappeared tomorrow I'd just push my repos to a different service.
On EE, there's nothing that we miss from the EE version, although we might end up going with EE after the team will grow. We also have dedicated dev-ops, otherwise having support for it would sounds good. And the pricing for EE if you go that route is much better than for GitHub Enterprise.
Personally I have mixed feelings about the "open core" model, as many times it's just a marketing stunt. But for now that's not the case with GitLab.
Seems like they were just following in the footsteps of one of Open Source's great prophets: https://en.wikipedia.org/wiki/Richard_Stallman#Events_leadin...
There is an opportunity for Gitlab here and I'm happy that they decided to make this announcement.
The community is the actual winner of this healthy competition.
Is this a joke? I mean for people looking for free private Git hosting, there is Bitbucket. This statement is like saying "free, but not really, really." The fact is if I want hosted Git hosting from Gitlab, I cannot reliably get it without paying at least $390 upfront for their EE plan. Too much smokescreen, too less actually on offer.
* issue management is better than GitHub's one but for very simple needs (90% of the repositories?) GitHub is enough and BitBucket is needlessly complicated (don't even talk about Jira).
* repository navigation is worse (finding the repositories themselves can be difficult if you land on the wrong page)
* wiki/pages are probably the same
* access control and general management is better
* pull request... I don't know. Our teams are small and normal communication plus git merge are enough.
That said, I've also used it in a paid, hosted environment supporting a team of 10. Again, our needs weren't overly complex and the integration with team software like Jira and Confluence were great (as can be I suppose, given the complexity of both tools).
I'm actually surprised there isn't more of a discussion around bitbucket and the cost of hosting smaller, private repos. Do most just dislike bitbucket or are you hosting bigger projects with multiple contributors which requires Github / gitlab services?
The mercurial support is great because of legacy code (I finally have come to admit that Git is superior for most purposes). The unlimited private repositories is great because we make loads of projects. I came from so many companies that would have this giant monolithic tree of tangled dependencies because they would check everything into one project. I fear this with GitHub's pricing model.
I find BitBucket's dashboard useless. It used to be decent but they changed it some years back. BitBucket's security was sort of disturbing as well but I believe they have added 2 factor authentication.
I will say that Atlassian's Jira used to be the best bug tracking but I have found that in the last couple of years it has become a complete bloated pig that is overly complex and slow. The hosted Jira is so awful that we contemplated just using BitBucket for bugs. We eventually switched to Youtrack and are loving it.
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.
And we're working hard to make GitLab.com reliable, fast and free too.
In my opinion its nice to have the ability to host it yourself and it was the primary feature attracting me to GL, followed by it looking user friendly for a few people I am working with who are not shell people, and what finally sold me is they clearly have a team which is focused on making the product better.
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 FOSS.
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), but my company prefers on-prem whenever practical for various reasons.
Self-hosted GitLab doesn't fit all the same uses as GitHub (I wouldn't use it for personal projects), but when it does fit it's great to have.
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
[1]: https://about.gitlab.com/downloads/
[2]: https://about.gitlab.com/aws/#uw2
Who gets to decide that features are enterprise only ? How are these enterprise only features: "Hosting static pages straight from GitLab", "git-annex", "git hooks", etc. ?
Get a crippled version that doesn't fit the reasonable expectations or pay for enterprise edition coming with a big bag of features I have no use for just to get the missing features that I can have on github for free (And I'm not a big fan of github)?
As such gitlab community is not very useful to me and does not seem to have a future because its chosen business model goes against its usefulness to people.
The EE edition features make a lot of sense for much larger organizations I suppose.
As evidence, just look at our Direction page: https://about.gitlab.com/direction/, or compare the CE and EE changelogs: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELO... vs https://gitlab.com/gitlab-org/gitlab-ee/blob/master/CHANGELO....
Note that our free, hosted GitLab.com runs EE, which means that EE features like GitLab Pages ("Hosting static pages straight from GitLab") are available to everyone.
That's not a feature that only large enterprises use–I run an open source GitHub organization and wanted to use GitLab as CI. It works! But I needed to reimplement an EE feature to do it.
To be clear, I don't think there is anything sinister about keeping features behind a paid firewall. That is how software developers have paid their rent for decades. I'm just saying that the EE features are not all "mostly interesting to companies with 100+ employees." Several of them are things I needed as a single open-source developer.
I've debated about buying EE to fill in the gaps, but you sell licenses in packs of 10, and I only need 2 :-)
Is there a reason why you didn't use GitLab.com, which runs EE and thus has Repository Mirroring?
> I'm just saying that the EE features are not all "mostly interesting to companies with 100+ employees." Several of them are things I needed as a single open-source developer.
Fair enough, I'm not saying our judgment of what is and what isn't interesting to smaller/single-person teams is perfect. If the general feedback of the community is that a certain piece of functionality belongs in CE rather than EE, we will consider bringing it to CE. We have done this in the past.
1. My hosting is way more reliable than yours :-)
2. I need to host the CI runners myself anyway, because you don't have the right config
3. I already have a private GitLab install, so it's no extra trouble
4. My repository mirroring is quite a lot better than yours, as it's instant, not hourly
5. I prefer to have a commercial relationship with important tools. You seem like nice people, let's see what happens when you get acquired. As long as you can't be bothered to sell to 2-person teams, I'll just run CE and have my commercial relationship with AWS instead.
You've got me there :) I'm sure your aware of our intention to greatly improve GitLab.com reliability and performance in Q1 2016: https://gitlab.com/gitlab-com/operations/issues
> 4. My repository mirroring is quite a lot better than yours, as it's instant, not hourly
Heh, care to share? :) Maybe we can take some pointers from your implementation. How does your repository mirroring know that the upstream repo was updated? Do you use webhooks on GitHub? That would actually be pretty easy to implement, an `update_mirror` GitLab API endpoint that GitHub could call to, hmm...
> 5. I prefer to have a commercial relationship with important tools. You seem like nice people, let's see what happens when you get acquired.
What are you afraid of?
> As long as you can't be bothered to sell to 2-person teams, I'll just run CE and have my commercial relationship with AWS instead.
Fair enough!
Bingo. Full implementation, in Bash: http://faq.sealedabstract.com/gitlab_mirror/
> What are you afraid of?
Mostly, that you'll get bought by the likes of Oracle. In spite of my quibbles about CE features, I think you're doing a (mostly) fine job of CE right now. But your acquirer will see CE as a cost center (there's no revenue) and will want to "streamline" by focusing on enterprise (where your balance sheet is). GitLab.com will also look like a cost center, and will either shut down, turn into a datamining opportunity, or go through the bad PR of no longer being free. I fully anticipate, in 5-10 years time, that I will be running a CE fork to get out from under your acquirer, just like StarOffice, MySQL, Hudson, etc.
Contrast with GitHub, who makes a silly amount of money from people like me. Their acquirer would be mad to screw up a winning formula.
The good news is, GitLab is such a good product that I still hugely prefer it even after "pricing in" the risk (cough, certainty) that my days are numbered. It is an amazing tool, it really shows that you care about it. For now.
I've asked our CEO Sid (you know, the "GitLab CEO here" guy) to chime in.
Understand, I want to believe. I want to live in a world where open core works at VC scale and over long timeframes. I'd love to run all my own projects that way, if it was possible. And who knows, maybe you will be the people to do it where everybody else failed.
It's just the available evidence suggests I don't live in that world. In my world, you have to pay money for things if you want them to last. I'd like to pay you money, but you don't want it, and that's weird.
Look at it from my POV. GitLab isn't "just" another tool for me, it's my homepage. I'm in there hours every day. I trust it to store my life's work. That's amazing! People literally kill to get that deeply embedded into their customers lives. But it's also a huge responsibility. You and I are in the honeymoon period right now, but when times get tough and we have 3 kids and a mortgage, it's going to get real.
You may not be in a position to speculate that far out, but I have to. I'm still going to need this product in five years. You might not need me.
GitLab CE is MIT licensed and will not go away in case we get acquired. Some companies (including Oracle themselves) are using GitLab CE with thousands of users (they rebranded it as Orahub, don't ask).
For our promises regarding being a good steward of CE please see https://about.gitlab.com/about/#stewardship
You might even get the community to develop EE features for you to sell :)
We've been using GitLab CE for a while internally and it's fantastic. Don't dismiss it because of some narrow-minded ideology.
Working with a on-premise GitLab CE has been just fine in a company with 20 developers, using Jenkins and later Go[1] for CI.
[1]: https://www.go.cd/
In general, I liked it, but it always irked me that its Ruby underpinnings made it hard to upgrade/migrate stuff (we basically just swapped LXC containers at one point, not sure how it was handled during the last upgrade). If anyone ever manages to do a credible alternative that does _not_ use Ruby in any way but keeps the overall GitHub-like workflow, a lot of operations folks will switch _instantly_.
(Like https://try.gogs.io/explore, for instance)
Also, like some commenters already pointed out, the CE edition was ridiculously limited in some regards - we mostly skipped the bits we didn't like and did product-level ticketing outside it (using Trac), with Gitlab issues used only for "techie" stuff, tracking fixes, etc.
But today I'd probably just sign us all up for GitHub and be done with it, or fire up a VM image from some marketplace - there's hardly any point in maintaining our own infrastructure or doing a lot of customization.
Did you mean Gitlab?
1. What things did you have to tweak?
2. Did you try our Omnibus packages for upgrades? It should be just apt-get upgrade https://twitter.com/J_Salamin/status/687884326629937152
3. What features of EE belong in CE in your opinion?
2. No, we had to tweak the source, so I don't think the packages were useful.
3. Static pages, hooks and merge approvals would be right at the top of my list. Audits would be nice to have, but we figured out how to do that on our own.
Also, issue handling needs some improvement. We just couldn't map our Trac workflow to it - but that's a fairly longer story, and it would probably be the same if we used GitHub.
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.
> What features of EE belong in CE in your opinion?
which means rcarmo knows they're in EE, but thinks they belong in CE.
Gitlab allowed us to do that without any hassle, even running inside an LXC container.
I had to do an upgrade from Gitlab 6.9 (source-based on ubuntu 12.04) to 8.3 (omnibus rpm on rhel7, managed via puppet) recently, and it was surprisingly smooth.
The package-based installer bundles all the needed software, which is quite okay for software like gitlab that often depends on specific versions of auxiliary software. It uses a built-in chef to configure its components.
I performed the upgrade in two steps, first to 7.14 (on the source-based install), then did a backup/restore to the new server with omnibus and upgraded it to 8.3.3 with yum.
Gitlab migrated the database mostly correctly (there were some issues with the LDAP provider; some users had the wrong provider in the database, but that was easy to fix manually. I'm not sure what caused it) which was quite a surprise considering I went up 2 major versions in two steps. Even upgrading the source-based installation went very smoothly even though it had to download a couple dozen ruby gems from the internet.
The upgrade also affected CI functionality for one of our users but I think that was because it relied on pre 8.0 non-builtin CI, and simply needed reconfiguration for the new system.
Afterwards, a point-release upgrade took a whopping 5 minutes (most of which was downloading and extracting the new RPM).
How does GitLab compare to Phabricator?
I use a command line for everything else in life; but with Git I'm hopeless.
Github OTOH has an extremely usable mobile UI.
What does this have to do with anything? Are you suggesting that service run on Microsoft Azure are not stable?
The downtime of GitLab.com is something the team are committed (see https://about.gitlab.com/gitlab-com/ - 'Disadvantages') to improve this year.
The only question left is if your servers are powerful enough to run gitlab. Maybe I'll sacrifice a goat for some new server hardware and 256GB of ram.
I think the spammer is trying to make a point! For starters, there seems to be no rate limit applied.
[1] https://gitlab.com/gitlab-org/gitlab-ce/issues
But if I press "sign in", I am able to sign up, with no notice about it being just a limited (45 day) trial. So so far I'm assuming that this is a perpetually free account, though I'm not completely sure yet...
The 45 day trial is for the case when you want to host gitlab-ee yourself on your own server.
1. Community edition 2. Enterprise edition 3. On our server
The 3rd option has this text: Free hosting for private repos? Sign up to get unlimited repos and collaborators.
Clicking on Sign up takes me to https://gitlab.com/users/sign_in which has clear options to sign in or sign up. It also has the text: GitLab.com offers free unlimited (private) repositories and unlimited collaborators, please sign up or in on the right.
In lesser words, it seems pretty clear-cut to me. They offer unlimited free hosting for your repos. I did not see any trial period anywhere. Maybe you went to the Enterprise option?
To clear things up: GitLab.com is completely free, with unlimited projects and collaborators. GitLab CE is open source and completely free. GitLab EE costs money and has a 45-day trial.
1. The Hosted CTA is the right-most one. People don't read that one. Eyes naturally go to the first CTA, and then compare it to the 2nd one. Based on the first 2, I expect the 3rd one to be another downloadable package, not a hosted option, so I don't read it.
2. The top nav-link is "gitlab.com" not "hosted service". If I don't know that gitlab.com is a git hosting service, I'll never look there.
3. As mentioned, features + pricing don't mention gitlab.com, so once you get off the front page, you lose any hints of a hosted option unless you know what the "gitlab.com" link is for.
4. The first headline that my eyes go to below the fold is:
That implies to me that "gitlab" is (exclusively) a self-hosted product, and isn't available as a SaaS option. Yes, it does also say "Or use our free SaaS GitLab.com" but you can't really expect people to read the text immediately below a headline that (effectively) says "not what you're looking for"Right now, since you're advising people to go self-hosted rather than gitlab.com, that might all be working in your favour. But when you get the performance + reliability of gitlab.com sorted out, I'd strongly advise you to make the SaaS option a lot clearer.
(I realise that I could submit a patch to index.html, but I don't think my 10 minutes of hacking is going to get you to the best outcome)
By the way, we're using self-hosted Gitlab at work and we love it. This isn't a knock against the actual product. In fact, I think Gitlab has improved tremendously in the last 18 months. I just wish they would be a little more up-front about their marketing efforts.
Anyway, opening sentence of gitlab's open letter: "The letter of GitHub’s open source community is clearly not addressed to us, but we’re thinking a lot about the issues that were mentioned in it."
Does that cover your concerns?
I think if github was the free software entity, and gitlab had no free software edition available, then the tone would be, as you suggest, totally inappropriate. However given the arrangement is the other way around, it seems quite reasonable they would hop onto this issue at this time, especially given the very clear caveat quoted above.
I'm not sure why offering a free software edition somehow gives you a pass. Both Github and Gitlab are commercial entities as far as I know.
Anyway, my concern wasn't a big deal, I was just a bit taken aback at the opportunism. In retrospect, I think my reaction was a bit overblown.
You're right that both github and gitlab are commercial endeavours - obviously very much in the same space - so I'd expect them both to pop up in any discussion about bug & feature trackers, community involvement, etc - especially if there's the potential to improve their business.
On the other side of the coin, I'm curious why Github seems to often get a pass by the free software community.
That's basically what they did. They said "hey, you have these issues with GitHub, we're covering them, AND we listen to the community".
I think it's great that they responded to it, since it proves they actually listen and care about what their audience thinks.
I can hardly imagine a better outcome. Now both GitHub and the developers have a choice to make; GitHub can either ignore the complaints or take them into account, and people can either continue using GitHub or start using GitLab (or something else). Nothing better than informing people in a kind, respectful manner.
> I think Gitlab has improved tremendously in the last 18 months.
I agree, IMO it's already better then github - I know people will disagree on that, but I find the UI way better - Easier to find things and navigate for someone who doesn't work in github very often (milestones for instance).
Custom templates: https://secure.phabricator.com/book/phabricator/article/form...
Votes: https://www.mediawiki.org/wiki/Phabricator/Tokens
It's better in almost every aspect than GitLab and GitHub.
See https://en.wikipedia.org/wiki/Phabricator for an (incomplete) list of open source projects using it.
Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.
I think GitHub is prettier, but having tasks separate from repos and having tasks be as sophisticated as they are in Phabricator and having such a better pull requests system, it doesn't matter? GitHub has to dumb down the user interface on their product to appeal to the least common denominator and maintain their growth. Phabricator is for projects where people care enough about their projects to learn the UI so they can get things done.
> Also, do they pride themselves for writing this in PHP?
As a user I doubt you're going to find your self caring about how it's written.
Not everyone can afford to be completely blase about their source control system going down or getting defaced.
Gitlab had its fair share of vulnerabilities, too, despite being written in Ruby. It's about the developers, not the language.
Have a look at their bug bounty program: https://hackerone.com/phabricator
Some of the issues we had with Phabricator:
1. Phabricator is actually a suite of different applications that do specific things (e.g. source code hosting, issue tracking, project management, ...). Although Phabricator ticked all our feature boxes, some of the components it ships with are very immature and/or don't get a lot of attention from the development team.
2. For some reason the platform as a whole feels like a CRUD layer on top of a data model. The UI and various workflows in the applications are very tightly coupled with the underlying data model. I guess that makes it easy to develop and maintain the various core applications of Phabricator, but it doesn't make for a very user-friendly or usable product.
3. We have ~150 internal repositories, we actively work on ~40 of them at any given time. The source code application doesn't seem intended for that many repositories (e.g. navigating to a specific repository is non-trivial)
4. Phabricator has a fundamentally different approach to "pull requests". It works really nice, but only if you commit to using the Phabricator Way Of Doing Things. However, our team has been working on Github.com for years, and we're so used to the Github-workflow that we couldn't get used to the Phabricator workflow.
In the end Phabricator just wasn't the right tool for us. It definitely has some attractive properties: it's easy to install and upgrade, the command line tools are solid and provide all functionality you need, and it performs extremely well even on a small EC2 instance.
(EDIT: formatting)
The features which aren't explicitly marked "experimental" work very, very well in my experience. Especially the code review part, which I find more pleasant to use than Gerrit.
> 2. For some reason the platform as a whole feels like a CRUD layer on top of a data model. The UI and various workflows in the applications are very tightly coupled with the underlying data model. I guess that makes it easy to develop and maintain the various core applications of Phabricator, but it doesn't make for a very user-friendly or usable product.
Have you got some examples? They're hiding the database pretty well IMO, and we haven't had many usability complaints that weren't about minor issues. Many of the experimental features are cumbersome to use though and we've turned off some of them again to avoid confusion.
> 3. We have ~150 internal repositories, we actively work on ~40 of them at any given time. The source code application doesn't seem intended for that many repositories (e.g. navigating to a specific repository is non-trivial)
Have you raised an issue about this? They're very responsive to issues encountered in real-world use and usually decide about feature requests by user demand. I do know that they're working on improving this - the "callsigns" will become optional, for example.
> 4. Phabricator has a fundamentally different approach to "pull requests". It works really nice, but only if you commit to using the Phabricator Way Of Doing Things. However, our team has been working on Github.com for years, and we're so used to the Github-workflow that we couldn't get used to the Phabricator workflow.
Their way of doing (or actually, not doing) pull requests is the most important feature of Phabricator. Their approach scales much better than the traditional style and is - in my opinion - the most important reason to choose Phabricator over Github-style tools. This might not matter for small projects, but in a company, it sure does.
Someone wrote it up quite nicely there: http://cramer.io/2014/05/03/on-pull-requests/
1. That's true; the non-experimental parts of the suite are mature and work really well.
2. This was most apparent in experimental features like Harbourmaster/Drydock, where you need a lot of clicking around to configure a basic build setup. Granted, that didn't apply as much to the core applications, but we didn't find those very user friendly too. The task detail screen in Maniphest, for example, is super-cluttered with all kinds of labels, links, and text in the main panel of that screen. Also, the fluid layout in Maniphest makes it hard to read task descriptions/comments because lines of text get very long.
3. No, we didn't, because we were going to switch away to Github Enterprise anyway. You're right about responsiveness of the team, we noticed that too, and that's really nice.
4. Exactly, code review is how Phabricator started and I can definitely see merits in their approach. However, we aren't interested in changing the core workflow of 15 engineers just because it's theoretically a better way of doing code review. We're getting actual work done just fine with Github's PR system, despite the flaws it has, and that was one of the main motivations to go back to Github (Enterprise, in this case).
Like I said earlier: I think Phabricator is actually a very nice tool and I can see how it works really well for large teams that are willing to commit to the code review style. It just wasn't the right tool for us :-).
I'd prefer it to be written in something else, too, but - the Phacility team are ex-Facebook developers. If anyone knows how to use PHP, it's them. They built their own, extensive web application framework on top of it (which is a remarkable achievement for itself). Phabricator is one of those rare examples that you can, in fact, write excellent code in PHP.
On top of that, they're running a bug bounty with generous payouts: https://hackerone.com/phabricator
Really the place that PHP is lacking is on the tooling/ops side of the projects built on top of it. A lot of what I have to work with still seems to be 15 years old. That said, it's getting better and other peoples' preferred tools have their share of problems as well.
Like what?
Management panels of hosting companies.
UltraDNS's website.
Salesforce.
1. Supports Mercurial - our repositories are currently in mercurial, and using any other tool would require switching to git (which we seriously considered while looking at tools).
2. Simple to maintain - if you have experience setting up other web applications based around LAMP, this is essentially very similar. The web interface even indicates setup issues to admins, from things which can cause issues to performance configurations in things such as MySQL and PHP.
3. The code review interface was more intuitive for myself and other engineers. From the command-line tool (Arcanist) to how it's conveyed to the user in the web interface. It did take a little time to fully comprehend and implement the process for using, but since implementing in Feb. of last year, after around 4 months we had near 100% adoption by the engineering department. The GitLab/GitHub interfaces I've found to not be organized intuitively -- the lifetime of an issue/changes seems (seemed?) more social-based and intermized where in Phabricator an Issue/Task is almost separate from the changes which can go into it, though they reference eachother easily.
>Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.
I had the same reaction at first (thought I wouldn't say it's pride?). In fact the first time I looked at Phabricator (~2012) I totally dismissed it for three reasons:
1. Written in PHP
2. Mentions pokemon on the front page
3. Marketed as "collection of open source web applications"
These led me to believe that it was at most some PHP glue some students hacked together to get different unrelated applications to play together. This conclusion is entirely wrong. I've since changed my mind about PHP - biased from earlier experiences there's no reason to think a reliable/stable application couldn't be built on it. Phabricator (I believe) started as an internal application at Facebook which has since become its own company. The code is very well organized (I've contributed some small changes), and there are some very bright people working on the project - I get the vibe that they genuinely want to solve the right problems rather than checking features off a list. There are very few dependencies on other libraries unless you specifically decide to enable extra features, and even then there's some support/documentation there to assist. Despite the light-hearted humor (see pokemon) that is a staple of the software (unless you enabled serious-business mode), the project is designed and developed by highly capable, quality professionals.
I couldn't have been happier going with Phabricator over GitLab.
That being said, just like any other fairly complete solution, it's quite opinionated about the right way to do things, and it's very different from github or gitlab. In particular, since it is not tied to git, it duplicates some of git's functionality in its own tools. In many ways I find those tools to be better than what git uses (arcanist just seems more well thought-out from a UI perspective), but it is a learning curve.
If you are happy with svn or hg, and don't want to have to switch to git, Phabricator is a no-brainer. If your team is a bunch of super-advanced git users, they may not like having to learn a different way of doing things.
Fortunately (for my team at the time, which was very resource constrained) those who hated it eventually won, but I, being kind of on the fence regarding it (wasn't keen on the UX, but liked the features), sort of wondered what would happen if someone improved the UX beyond the tipping point.
I'd be happy to be proven wrong.
RhodeCode actually supports Git, Mercurial, and Subversion.
There's a big difference between Kallithea and RhodeCode. Kallithea development is stale, and there's not a lot of things going on in this project.
RhodeCode is adding new features constantly, and the project is really active.