* block trolls from interacting with an organization, short of filing a support ticket
* install pre-receive hooks without using the pull request infrastructure
* set up status checks (the PR equivalent of pre-receive hooks) for pull requests that require force pushes, allowing some external check to replace git's usual fast-forward check
* have status checks apply to individual commits, not trees, so that you have style or copyright or whatever checks on each commit
* disable pull requests
* enforce rules for creation of new branches or tags
I admit that none of these features are dealbreakers, but they all have legitimate use cases, and they'd all be trivial if you were using a regular UNIX-based git server.
On the other hand, the usable interface of GitHub wouldn't be available to you if you were using a regular UNIX-based git server, and that is a dealbreaker. :)
Of course, you have issues and discussions that are tried to Github's platform, but we don't have any universally accepted format for it except email anyway.
I have seen instances where they have been cowards, regarding DMCA's and acquiescing to threats, but that is a minor sin. I don't expect every organization to fight every fight worth fighting.
1. Gitlab themselves admit that Gitlab.com is bad[1]. Making a cloud-based software development platform is hard, and Github has some of the best engineers working on scaling the service. Gitlab doesn't have nearly as many resources.
2. The community is thin[2]. Almost all of the largest projects on Gitlab.com are Gitlab. Gitlab CE is maintained by only a handful of people. Go through the list of top contributors on Gitlab.com and you'll find that they have almost zero "personal projects" hosted there. If the developers of the service don't even use it, why should I?
3. The UX of Gitlab is honestly quite poor. At best, it's a clone of Github's UI. At worst, it has way too much scrolling thanks to inconveniently placed whitespace, poor performance, a confusing information architecture, and oodles of low-contrast text. I personally find getting around Gitlab to be tiring and confusing. Here's an easy example: from the Contributors tab of a project [3], how can I see more about a contributor? You just can't. There's lots of little papercuts like this scattered across Gitlab. Not to say Github is without papercuts, but it certainly has far fewer.
[1] https://about.gitlab.com/gitlab-com/ [2] https://gitlab.com/explore [3] https://gitlab.com/gitlab-org/gitlab-ce/graphs/master
What I don't understand right now is why they aren't trying to copy GitHub as much as possible ... when it makes sense of course. I've been studying both GitHub and GitLab's design in detail, because I want to incorporate my technology into their branches and commits page, and I've found the user experience between both quite striking.
When I get some time this week, I would like to submit an issue with GitLab to let them know in more detail what I think they can do better, but here is just a synopsis:
- I still can't put my finger on it, but there is something off about the font.
- Avatars with 50% border radius is a bad design choice in my opinion. The problem with creating circular avatars is they hide too much of the image and they create a focal point towards the center of the image. If your avatar doesn't have a natural center focus, it will look bad and create unnecessary eye strain, since your mind will naturally try to fill in cropped areas. Keep it simple and use a simple border radius of 8 or less.
- Avatars on the commits page are too small. I'm not sure if this design decision was the result of the Gitorious acquisition, but Gitorious had this problem as well. Using small avatars has its place, but not on the commits page since this page is designed to help you better understand who did what quickly.
- How the commit message is revealed in the commits page is too jarring. If you click on the ellipses at
https://gitlab.com/gitlab-org/gitlab-ee/commits/master
and
https://github.com/gitlabhq/gitlabhq/commits/master
you'll better understand. The problem with GitLab's implementation is the strong focal point is the avatar and when you click on the ellipsis, your eyes will get dragged down with it when the message is revealed. Just copy GitHub and use a bigger avatar and have the commits message reveal below the strong focal point (avatar)
- The calendar icon on the commits page is visually too strong and should be removed.
- The clipboard and other elements on the commits rows creates an unnatural balance/flow. If you look at GitHub's commits page, the clipboard, commit sha and browse tree icon are equally balanced in size and weight, which creates a natural horizontal flow. You can sweep from left to right and it won't create any unnecessary jarring effect.
This is just some of the things that I've thought about when I was looking at the commits page and I really don't understand why they aren't copying GitHub's UI in a lot of places. The amount of money that GitHub is investing in their UI vs GitLab's is quite significant, and it should be obvious that GitHub is way more capable of producing a better user experience, so why not copy it?
GitHub does that too, of course. But they are also basically a social networking website for individuals and organizations in the software industry. Prominent companies put code on GitHub because that's how you maintain a public presence in the developer community today. Even though the GitHub repos are more often than not mirrors, with the code actually being developed with internally-hosted repos and tooling.
So as far public destinations for open source code, GitHub has that market pretty sewn up for now. However, there's lots of competition in the "charging money for private services" market. Atlassian is a giant in the enterprise world, and I'm sure GitLab is doing well too. GitHub sells private services too, of course. Lots of people argue that Bitbucket's tooling is better, and even the paid version of GitLab is insanely cheaper... but GitHub does have an advantage in being able to leverage everyone's familiarity with it.
I think Gitlab's current user base is for developers/startups who want VC backups for their private codebases. I'd probably use Gitlab if I were developing a private project that I didn't plan on releasing.
Github, by design, is friendly towards people who want their code to be open to the world and encourage exploration of interesting projects. It's a great for sharing research code, and many big companies (Google, Facebook, Apple, Microsoft, Mozilla, Disney, Pixar) already put their stuff there. It's highly unlikely these big fishes will move to Gitlab anytime soon.
Gitlab is the first piece of open source I've seen in probably a decade where I haven't a single bad word to say for it, their attention to detail is superb, starting with the installation process. I'm usually by default a critic of pretty much anything I encounter (aka. "typical HN comment author") but I find myself advocating Gitlab constantly
now does this mean that Python will completely switch away from Mercurial? this was one of the major projects still using hg
what does this mean for mercurial's global adoption vs git?
also, i don't understand why the free software aspect of gitlab wasn't an important argument in the decision... that seems like a key element of the difference between the two platforms.
Mozilla, Octave, and Hedgewars are a few remaining projects that still use hg. For them, I will continue to improve, promote, and use Mercurial.
Their reasoning for using Github have nothing to do with the technical merits of git or hg or with the freedom of the software or platform. They want more contributions and they figure using the popular platform is the way to obtain them.
Seriously, I like the idea. It will give visibility for who contribute and might bring some new contributors.
