Hacker News Reader

Comment by pcx | Hacker News Reader

Great to see GitLab gain momentum in FOSS. It's a great fit for small teams too, it's easy to setup and keep updated. It's more important than ever to help GitLab gain adoption with GitHub making it free for private repos. I love GitHub as much as any developer, but I believe having a free, open alternative to it is important.

I wish GitLab would improve their free-version of Merge Request reviews though, Github's is much much better right now.

View on HN

I'd love to hear more about what you dislike about merge request reviews. At work we've been talking about migrating looking for alternatives to GitHub over dissatisfaction with its code review interface, and, of course, GitLab is on the list of ones to check out.

Ability to review diff between two versions of PR is a great missing feature in GitHub. When dealing with large changes, GitLab review flow is IMHO easier for reviewer. Gitlab store each push of a MR branch as different version (as hidden refs), which make the feature possible. In GH, you force push a branch, you loose the old code for good, so reviewer has to remember why he did that comment before to see if it is still relevant.

This is such an important feature that has a direct impact on code quality and time savings that I'm not sure why it isn't a priority feature. As a reviewer, having to choose between "review everything again" or "trust the submitter didn't introduce extra changes in the revised pr" is such a terrible choice to have to make.

They added this (reference and comparison to old heads of a PR) at about the start of the year.

I think this only works when diffing between commits in the same PR, but not when force pushing the same commit over and over again

Couldn't find the feature today when doing a large review. Do you have to enable it somewhere?

In the top left, there should be a "changes from..." drop down menu that will let you choose which commits you want to view. The default is "changes from all commits".

If you're on GitHub Enterprise, availability will depend on the last time your company has installed updates.

That is not the same feature. It requires you to always add your fix in a new commit add opposed to amending the commits and maintain a clear purposed commit list.

I think the more official Git way of doing it would be to collect all the changes in separate commits, and then squash merge them at the end of the code review.

that features has been in bitbucket for ages

In my experience, GitLab's MR UI really lacks performance when the diffs pass a certain length. Similarly sized diffs in GitHub don't seem to have this problem, though.

I think of it as additional incentive to maintain smaller patches for ease of review, but sometimes changes are necessarily large due to complexity. It can be obnoxious to be hamstrung like this.

Honest question: isn't it far better to review the patch locally on your laptop? I always do this, primarily because I like to be able to go through the callers of functions that the patch modifies, look at the callers of functions that have been introduced, etc.

My decades-long complaint with every single code review system I've been forced to use at my workplaces (which no system I've seen fixes so far) is that they don't let you browse code and examine the diff in its native setting, so to speak.

GitHub hides large diffs by default though so maybe that's why

So does Gitlab in my experience.

I mostly like their merge request UI but one big missing feature for me as an easy way to view and review commit messages. For complex patches the commit messages can be vital.

One thing I find annoying and occasionally hazardous about Gitlab merge requests is that per-file diffs which exceed a certain length are collapsed by default. This introduces risk since it is very easy for a reviewer to skim right past the collapsed file name, since one's eye tends to be drawn to the more salient red/green diff.

GitHub does this too, and it's awful. Why would anyone want to skip reviewing the biggest changes?

I have developed a habit of going through my own pull requests immediately after opening them, and adding a "don't forget this file" comment to all the ones that get collapsed.

'Cuz yeah, I've seen some nasty stuff sail past code review simply because it's so easy to accientally miss those files.

Good one, I'm going to do that too, thanks. It's pretty nuts how broken a UI is that it forces us to do stuff like this though.

I feel like everything about the GitHub PR UI is targeted at reducing the code review job to being a human style checker. Minimal context, no code navigation, abysmal rename following.. it's really hard to review the design of a change.

I'm guessing for things like package-lock.json.

Though it can certainly hide much more relevant-to-reviewers changes easily.

The reason for the automatic collapse is due to performance. Also it's not uncommon (depending on the language and framework you are using) for the biggest files to be just a mere dependency lock file kind-of update.

Code search, Gitlab doesn't have a code search feature. Paraphrasing The code search functionality can be achieved by adding Elasticsearch. We haven't added elasticsearch yet so cannot comment on the experience of using it.

Sourcegraph might be better: https://about.sourcegraph.com/

It looks like code search is available for self-hosted GitLab instances, and also for paid groups on gitlab.com.

It could be a little while before global code search is available to non-paid users, according to their search roadmap documentation[1].

[1] - https://about.gitlab.com/direction/global-search/

Our current approach is to make code search available for Bronze/starter and above. We appreciate your feedback on enabling it for non-paid. This is the Epic we are working on, feel free to leave feedback here as well. https://gitlab.com/groups/gitlab-org/-/epics/1736

Thanks for the link and engaging with the community. That led me to https://gitlab.com/groups/gitlab-org/-/epics/429 which sounds like a challenge.

Although not at GitLab.com scale, I've worked on a few search-related projects (often using Elasticsearch) in the past and would consider offering some ideas.

Does GitLab have a policy for attribution/licensing of technical design input from external contributors? (this is partly out of curiosity in general -- I don't know for sure whether I'd have anything to add that your team wouldn't already have thought of themselves)

We have made some solid progress on reducing the index size recently. This comment has a nice summary on the preliminary results of what we are working on. https://gitlab.com/gitlab-org/gitlab/-/issues/27918#note_353...

We always welcome the sharing of ideas and feedback. Just tag me on anything I should review. GitLab ID is @JohnMcGuire

We love external contributions. This page should help answer questions about contributing. https://about.gitlab.com/community/contribute/

Great, thank you!

Merge requests seem to merge both branches in to each other. This is not the behavior I would expect. It doesn’t seem to be that way on github but I could be wrong. I see this behavior when to long lived branches are merged.

My git-fu is average level so its possible that I’m missing something obvious here. For me the easy solution is to just merge on the command line.

Personally, I despise how the file header moves around as you scroll over the files.

Does anyone else have things that make the switch from GitHub to GitLab a hard sell?

I'm always curious why open source projects don't embrace an open platform, although I get that GitHub is fantastic in a lot of ways. I'm guilty of it myself, but I've reached the 50/50 GL/GH split as I try using GL more.

I don't think there's any one single blocker that's keeping me on GitHub. It's just a bunch of little annoyances with GitLab that add up to make it not worth it -- either UI quirks, or ways in which third-party tools integrate just a little more easily with GitHub.

Yes, GitHub absolutely has a bunch of annoyances, too. (I listed a bunch of them here on HN in response to a question by Nat, just the other day!) If everyone were using GitLab first, we'd probably find excuses to put off switching to GitHub, too.

To attract users, you've got to have a pull. If that's "open source", then it needs to be a way in which the closed-source nature of GitHub is hurting my daily workflow. If it's "user interface", you need to be such an improvement over GitHub that it's worth the cost of switching. If it's "cost", that's tough because GitHub dropped prices and is now $0 for many users, and you probably don't want to get in a price war with Microsoft (see: Netscape).

It doesn't have to be the same pull for every customer, but every customer needs at least one.

"We're just as good as that big popular project" isn't a pull. I've seen hundreds of projects try that, and it never works.

This sums up my attitude towards it. Opportunity costs factor into switching cost; am I getting enough ROI for the switching costs vs something else I could be working on?

Gitlab is open core but not open source either, I think. I am in the same boat as you though!

The Community Edition is open source.

The community edition is a castrated mess with ads in it. I administrate a gitlab instance for a university and gitlab is hurting me in so many ways.

1) it had a message that tells you that the elastic search is so much better and that your admin can enable it (if he would only switch to enterprise)

2) it pretends to have functionality only to have it hidden behind an "available in ee" banner

3) it has a new functionality where it annoys everyone that has a new ip (24h disconnect anyone) that can't be disabled (only through patching) and suggests that enabling 2fa helps, but is send regardless of 2fa

And every function that gets cut out and hidden behind the enterprise banner iy forever lost to you, because even if you implement it yourself it will nevet get merged since the function exists, in enterprise...

Ps yeah there is a free enterprise license for universities, but it is not available for staff or external users (other universities) and the licensing model is so unflexible that you can't mix "free for students" and "pay for staff" or "students get enterprise" and "staff get basic features"

Pps I had to patch out more than one thing over the years this was just the first thing that came to mind

Thanks for the feedback on the GitLab for Education program. In the spirit of iteration, we started the program as an MVC - offering free licenses for teaching and learning related purposes. The program has grown significantly since then and through meaningful feedback from our members, we’ve come to realize the structure is not ideal for Universities to implement at an enterprise level. We have an epic open to restructure the program and welcome constructive input. https://gitlab.com/groups/gitlab-com/marketing/community-rel...

Thanks for reaching out through hn. I will take a look at the epic you linked. Those are indeed many issues we faced (and other universities as well. there was even a discussion of somehow trying to license one github instance for all universities in the state although I'm not sure if this ever amounted to anything)

I'm really interested in the development of this issue so thank you again for reaching out.

Ok I can't edit my original comment so just to clarify:

GitLab doesn't serve ads it only pushes out messages to users that they could have a better product if only the admin would shill out some bucks.

It's ok if admin settings are greyed out with a remark like in old freewares to tell you features you could have in the enterprise product, but if the software tells any user that they are missing out it is more unnescessary work for the admin to explain that we don't have the money to pay for every single student, most of which only create an account without pushing any code, just so that the search can work over all wikis and not only the selected one.

So again it's more like the "buy winrar" or "go pro now" nag and _not ads_. Sorry for the confusion

> The community edition is a castrated mess with ads in it.

I understand your frustration with FOSS pushing you toward buying proprietary software.

But your lede will mislead people into thinking CE gets revenue by serving up third-party ads because that is what "ads" mean for web services 99.99% time the term is used on HN.

Are ads a new thing? I self host gitlab but haven't used the UI much as it is only a personal repo.

I called it ads, but it really is more the promotion of enterprise features and yes it is "new" since it only started popping up in the last year or so. It also seems that they are trying to dial it back, but gitlab really started getting aggressive with annoying little things like that and is getting on my nerves from time to time.

On a positive note it got quite a bit more responsive in the last 4 or 5 five years since I started hosting it and even thought we got some regressions and bugs and problems with releases we didn't have any data loss (that we know of) or major security problems. Most of the security problems are in the enterprise functionality anyway (elasticsearch and grafana pop up regulary)

How about antispam features, are those still only for Enterprise?

Sorry since I only provide access to students, faculty and collaborating universities (so no open registration) I never needed antispam functionality, but can't remember seeing any entry in the administration interface or config as well.

Open Core is pretty much defined by an open source "community edition"

I truly believe it's because github has become a social network and developers use it as popularity contest. They want their commits to be there just like influencer wants to be on Instagram not on my fairly unknown platform.

I can confirm, this is the exact reason I made two copies of (shameless plug) the SpicaStack project earlier this month. GitHub's reach, network and stars help fellow devs and users discover our forks, while GitLab's exportability and amazing CI will let us actually work on it.

How do you keep the repos in sync?

You can setup git push to push to multiple repos.

git remote set-url --add origin ...

I use GitLab as the primary source, and mirror it to GitHub.

Or, I would have, if the builtin GitLab mirroring feature wasn't broken for pushing to GitHub.

I use multiple hosts to backup my repos: I host gitolite.org on a $5 VM and then have it configured to automatically push to gitlab and GitHub on every change.

My guess is some form of:

git checkout master

git pull github/master

git push gitlab/master

It's quite easy to set a git repo up to push to multiple upstreams. https://gist.github.com/bjmiller121/f93cd974ff709d2b968f also see https://stackoverflow.com/a/849960/308851

Absolutely - people now ask to see your Github repo as an integral part of your CV without even really considering if you might use another service.

And you don't exactly want to pitch to them how you don't have your code on Github because you use this other "fringe" service which even if they look at it they are going to find unfamiliar.

I now host 50/50 on Gitlab / Github because I'm not really affected by this, but I'm conscious of it.

GL is not browsable with JavaScript disabled while GH is.

Wonder how Gitea[0] stands on this line? It seems the easiest to setup for small teams.

0: https://gitea.io/en-us

I use Gitea for my own projects, i.e. I do the setup myself and it's trivial. It uses SQLite as backend, so no complex DB deployment.

It's very easy to deploy, consumes few resources (you can run it on a low-end VPS). It even has Jenkins integration.

However I don't know how it scales to big teams and projects since I only use it for myself. And I'm not entirely convinced by its security track record, but it looks like things are improving.

Why is this a hard sell? How many people does this really affect? And why disable JS on GL?

A Turing complete language executing unsigned code in a sandbox that allows HTTP and HTTPS requests to 0.0.0.0/0 and ::/0 is not something everyone wants in their life.

I run noscript without any whitelist at all, and considering how popular noscript is I doubt I'm alone here.

It makes the modern web so much more pleasant, paradoxically by breaking it, now that user-hostile machinations are the norm.

And yes, gitlab's web interface is substantially more annoying than github, in my experience.

It's not a hard sell, but it is certainly an inconvenience. I prefer to browse with javascript off by default and only enable it for sites that absolutely need it. I've had issues where sites using JS have caused a single core on my laptop to spin at 100% thus affecting battery life negatively.

In some cases "I'm browsing GitLab" might be the exact impetus for someone's attempt to disable JS. As noted above, GitLab is sluggish. I was an early adopter/advocate for GitLab, but you can feel the bloat on every page and I no longer use it.

Gitlab CI pipeline was a deal breaker for our organization. Lots of UI bugs, quite a few issues with CI nodes hanging, and ultimately their yaml job configuration system turned out to be too constrained for our needs. We eventually switched back to github and jenkins. This was more than a year ago though, so I expect some of those issues have improved during that time.

Product director for CI/CD here - we have tried to focus on improvements around making more complex pipelines easier to manage, but I would love to hear what you ran into just to make sure we are closing the loop on all the important ones.

I like GitLab and GitHub quite a bit, but I lean toward GitLab for the simplicity of a unified tool chain.

However, I think GitLab can only really shine when you host it yourself. In 2020, on-premise/self-managed anything is kind of a hard sell, but the reliability and performance of gitlab.com leaves a lot to be desired. (So much so, I often think about trying to work for GitLab so I could help from a reliability perspective.) I stuck my neck out for GitLab in a previous organization and we ended up migrating from github.com to gitlab.com. This set me up for some embarrassment for every outage they experienced last year which felt surprisingly frequent. But if you have the resources, self-managed GitLab is great!

tl;dr: gitlab.your.org > github.com > gitlab.com

Reply on news.ycombinator.com