Comment by scrollaway | Hacker News Reader

Comment by scrollaway | Hacker News Reader

I've been a long-time Github user and believer and vaguely followed Gitlab since their beginnings. Much as I admired their company and business, I had a lot of problems with their UI, UX and scattered focus.

Then very recently I've had to use Gitlab for a variety of new projects. And just... wow, it has come a long way.

There is an incredible amount of tooling and features, native to Gitlab. It's actually scary, and in some places even gets messy (feature overload). But a lot of it is useful stuff Github really should be offering. Things like more metadata on projects, subprojects. A very in-depth permission system (invite users with read-only access, issue-only access; membership expiration, ...). Branch protection integrated into various features.

Native CI! That's the big one. Travis is terrible. I used Gitlab CI to deploy one of my most recent project and ... it's been great. Was very simple to configure, felt a lot less magic and constrained than Travis, and it's very well integrated into Gitlab.

All this to say that I'm just about converted. Unfortunately, I have my 10+ year old profile on Github which includes membership to various projects and orgs, but I'm now pretty definitely using both platforms.

Edit: Here's my Github profile so people know I mean business when I'm praising Gitlab. https://github.com/jleclanche

>"I've been a long-time Github user and believer and vaguely followed Gitlab since their beginnings. Much as I admired their company and business, I had a lot of problems with their UI, UX and scattered focus."

I had a similar experience where we had gitlab in a previous job(recent past.)

The scattered focus seemed to be manifest for me anyway in their documentation. Finding documentation often involved going down a rabbit hole of user issues rather than looking in the official documentation. Additionally I found a lot of the documentation seemed incomplete and read more like internal notes than anything else. The contrast being github which has very polished and thorough documentation.

What is the topic in our documentation you think we should improve first?

Thoroughness? Accuracy? Here's an example. Someone attempting to upgrade their omnibus package installed instance will likely find the following resource:

https://docs.gitlab.com/omnibus/update/

This page links to the following "upgrade recommendations" resource:

https://docs.gitlab.com/ee/policy/maintenance.html#upgrade-r...

This above page states "We encourage everyone to run the latest stable release", we contains an embedded link. And when you follow that link it returns a 404 with a cutesy error page! See for yourself:

https://about.gitlab.com/blog/categories/release/

Further none of those pages explains how to pass in a specific version of the omnibus package to satisfy the upgrade process in the even that the latest version fails because the upgrade version differential is not supported.

It was really frustrating. And this is but one small example of course. But I think this is typical.

Thanks for the examples. I've asked someone to look into this. And we'll consider setting up a service to scan for 404s in our docs to prevent this in the future.

Let me reiterate Sid's thanks for picking this up for us.

I've raised an MR to fix the broken link issue: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21820. It'll be merged in due course.

I've raised an issue on our documentation to have the second point you raised looked at in more detail: https://gitlab.com/gitlab-org/gitlab-ce/issues/51666.

Thanks again!

I always find myself being bounced around different pages in your docs to find information about the same topic, and often also have to get bounced to your blog posts. It's hard to know when I've got all the info.

There are so many different places containing parts of the docs about your CI, for example.

Thanks, I recognize what you mean, blog post content that is not in the docs. I'll bring this up with the docs team and we'll try to get better at this by coping the blog post to the docs and linking the blog to the docs for the most up to date content.

I honestly don't understand why anyone uses GitHub for professional projects. It's inferior to not only GitLab but also Bitbucket.

"No one ever got fired for buying IBM."

I feel like Atlassian is IBM in this scenario. Bitbucket, JIRA and Confluence isn't everyone's favorite but you know they get the job done.

Of course, IBM has Rational Team Concert. It did... everything. But even teams within IBM were switching to GitHub Enterprise last I was there.

I use all three, and I still like GitHub. It works well, and it's incredibly well supported in the wider ecosystem of services - every CI product, bug tracker, comms product and analytics tool you can think of integrates with Github. Plus, for most large-ish projects, the web UI isn't where anyone spends much time so it doesn't really matter.

Network effects really, that and name familiarity possibly?

Well, because it's cheap, I have literally no issues or problems with it, it has all the features I need, integrates with everything, and is the most popular repository of open source code.

Why move unless there's a compelling reason to?

I dont think so, Github has way better integration with host of products and Nicer UI than either of the two you mentioned.

When I hear "Github has better integration" I think "You need better integration because half of Gitlab's features are provided by third parties on Github".

I don't care about the integrations on Gitlab because it already has everything I need, plus they ship new features at a rate of more than one per decade.

Well that or Unix philosophy of do one thing and do it best.

Mostly because of the "hub" part. It used to be the place where everyone else was. Up until the Microsoft buyout when people started jumping ship in droves.

I'm intimately familiar with GitHub's UI from both my OSS work and previous employers. I know GitLab can do everything GitHub can do (and more!) but it infuriates me how long it takes me to figure out how to do things I can do in my sleep on GitHub's web UI.

I don't think it's just a familiarity thing; I've been using it for months and still haven't adjusted. Gitlab's UI/UX has gotten better by leaps and bounds, and I prefer it to BitBucket, but it still feels like it has a ways to go.

Starting out with GitLab and then moving back to GitHub, I feel the exact same, but in reverse, heh, so you're not alone

Hah! Utterly delightful. So much for thinking "oh, it absolutely can't be a matter of familiarity"

I use GitLab exclusively these days. GitHub annoys me because I can't turn off PRs for mirror repositories, so I end up either having to sync or to manually tell people to take their PR and redo it on GitLab.

Thanks for the balanced viewpoint! Appreciate you sticking with us :-)

It certainly seems to fill a niche.

That said, I rather miss the minimalism and focus on individual developers (vs organisations and processes) of early Github.

Do you think that focus is gone?

I find both Gitlab and Github have plenty of focus on the dev (Github more so). It just so happens that Github has developed a lot of tooling for orgs and projects since.

Compare to Bitbucket's profile pages for example: https://bitbucket.org/astanin/

Do you think that focus is gone?

Obviously, this comes down to opinion, but honestly: yes. In the case of GitHub, the point where I reached that conclusion was when they added built-in enforcement of code review workflows. A feature which I seem to recall they copied more-or-less directly from GitLab...

(And I'm not saying it's wrong for everyone. But diversity is nice...)

I'm not sure I follow. Do you think improving in other areas means the focus is no longer on the dev?

Github, when it came out, was the only platform that even had proper profile pages for developers. They coined the whole "social coding" thing. I find that whenever I interact with other people on the site, I actively look at their profiles, their contributions, etc.

An example of a recent-ish feature they added which IMO is a good example of "focus on the dev": Comment authors are tagged as "Owner", "Member", "Contributor" and "First-time contributor" in comment streams.

> Github, when it came out, was the only platform that even had proper profile pages for developers.

This turns out not to be the case. Sourceforge had many or all of these features in the early 2000s.

The same way FTP had all the features of Dropbox before Dropbox was a thing?

Usability matters. Sourceforge was atrocious.

No, it became atrocious. The world moved on and SourceForge did not, which is why superior offerings arrived.

And to your first "question", no. It had them in almost exactly the same incarnation as modern sites, but with a UX design language rooted (fatally) in the "best practices" of the web at the time. Unlike all the crazy things you'd have to do around FTP to get it to act like DropBox, SourceForge had the mentioned features built in from the start.

It doesn't really win GitHub any prizes to pretend otherwise, so I'm not sure why the pushback against simple facts.

I'm not sure I follow. Do you think improving in other areas means the focus is no longer on the dev?

Yes. There are always trade-offs, especially when you're adding user-facing features as slowly as GitHub [1]. The author tags are one of very few that focus on individual developers. About the only other one I can think of is the option to curate the repositories that appear on your profile page (welcome, but took years of asking...)

[1] Which isn't, in itself, a bad thing -- stability is good, and GitHub's launch feature set turns out to be a pretty good match for what I want)

The enforcement of those code review workflows is set up on a per-repository basis. So e.g. if you get access to <someorg>/repo you need to go through that, but not in <yourfork>/repo.

I guess in some sense you could say it's a focus on organizations, but on the other hand it's a glaring omission of a feature that you could have implemented with a pre-receive hook years before either GitLab or GitHub had it, so it would be strange if they didn't add it.

Reply on news.ycombinator.com