New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitLab #56

Open
jamiebuilds opened this Issue Jan 15, 2016 · 32 comments

Comments

Projects
None yet
@jamiebuilds
Copy link
Contributor

jamiebuilds commented Jan 15, 2016

Over and over again today people have brought up GitLab. It seems like a good product but I do not have any experience with it.

I want to open a thread for people to discuss:

  • Positives of GitLab
  • Negatives of GitLab (If there are problems I want them out in the open)
  • Are projects willing to move from GitHub to GitLab?

If it is a truly superior product I would consider moving all of my projects over there and I'd talk to the Babel team about moving everything there.

If anyone has migrated a project from GitHub to GitLab, could they detail what is kept/lost in the transfer? Does it keep issues/PRs/etc?

@theofidry

This comment has been minimized.

Copy link

theofidry commented Jan 15, 2016

IMO GitHub has a better UX and more features than GitLab. The advantage of GitLab is that you can freely install it on your own servers, hence a very cheap solution if you want unlimited private repositories for your team, compared to GitHub private repositories pricing.

Of course that's my experience with it, maybe someone will have a different one :)

@martndemus

This comment has been minimized.

Copy link

martndemus commented Jan 15, 2016

The big upside to GitLab is that it is all open-source. Their mission statement almost completely addresses all issues raised in the README.md.

@petetnt

This comment has been minimized.

Copy link

petetnt commented Jan 15, 2016

Major con: The slowness @cvrebert pointed out is a major pain point for myself at the moment. I haven't hosted my own projects at GitLab so far, but just browsing other projects is quite terrible: every action takes seconds to complete. Every time you press anything you are looking at a 1-10 second wait.

Con: Bots are tearing up repositories right now: https://gitlab.com/groups/gitlab-org

Pro: It somewhat implements templates for issues-point from dear-github

Pro: Unlimited private repos for everyone

edit:

Con: Registering a new account with GitHub account resulted to 404 page. Trying to file an issue with about it lead to really vague 422 page 🐑 Okay now I killed the whole thing with history.pushState. Less polished UX than with GitHub I guess.

@damienalexandre

This comment has been minimized.

Copy link

damienalexandre commented Jan 15, 2016

GitLab has some great features, like the "reactions" system that may allow to get rid of 👍 in the issue comments: https://twitter.com/gitlab/status/687930087057027073

@nicosomb

This comment has been minimized.

Copy link

nicosomb commented Jan 15, 2016

Cons: gitlab has less popularity for promoting projects.

@DouweM

This comment has been minimized.

Copy link

DouweM commented Jan 15, 2016

IMO GitHub has a better UX and more features than GitLab.

@theofidry We're aware that the GitLab UX is less polished than GitHub's in some regards and we're working hard to make it better with every monthly release. What kinds of features do you find GitLab is lacking?

Major con: The slowness @cvrebert pointed out is a major pain point for myself at the moment. I haven't hosted my own projects at GitLab so far, but just browsing other projects is quite terrible: every action takes seconds to complete. Every time you press anything you are looking at a 1-10 second wait.

@petetnt We're aware that GitLab.com is currently unbearably slow. We are sorry, and are working on improving that in Q1 2016: https://gitlab.com/gitlab-com/operations/issues

Con: Registering a new account with GitHub account resulted to 404 page. Trying to file an issue with about it lead to really vague 422 page 🐑 Okay now I killed the whole thing with history.pushState. Less polished UX than with GitHub I guess.

@petetnt Hmm, errors like that shouldn't happen, GitLab is a very stable product even if the UX is sometimes lacking. As of two days ago, GitLab.com runs on 8.4.rc1 (8.4 is due to be released on the 22nd), so it may currently be a little more volatile than a final release would be. If you were unable to file an issue on gitlab.com, could you perhaps file it on our GitHub mirror at https://github.com/gitlabhq/gitlabhq? You can mention me and I'll get to the bottom of it. Thanks in advance!

@lenovouser

This comment has been minimized.

Copy link

lenovouser commented Jan 15, 2016

@petetnt the issue with the bot's also occurs on GitHub. I myself e.g. have subscribed to google/material-design-lite and it get's spammed by bots regularlely. They post stuff like phone numbers and links etc. etc.

@chadwhitacre

This comment has been minimized.

Copy link

chadwhitacre commented Jan 15, 2016

@Changaco mentions at gratipay/inside.gratipay.com#446 (comment) that GitLab does not have repo watching yet, though this comment may indicate otherwise.

@Changaco

This comment has been minimized.

Copy link

Changaco commented Jan 15, 2016

Con: as mentioned above, GitLab doesn't allow watching a project you're not a member of, see https://gitlab.com/gitlab-org/gitlab-ce/issues/9013.

@martndemus

This comment has been minimized.

Copy link

martndemus commented Jan 15, 2016

Pro: GitLab responds very quick to issues concerning GitLab.

@DouweM

This comment has been minimized.

Copy link

DouweM commented Jan 15, 2016

@ariya

This comment has been minimized.

Copy link

ariya commented Jan 15, 2016

Some weeks ago I experimented with the idea of Varnish/nginx in front of GitLab, primarily to workaround (not to eliminate) some of its performance problem. However, I didn't complete it enough to form an opinion whether the experiment is successful or not.

@chadwhitacre

This comment has been minimized.

Copy link

chadwhitacre commented Jan 15, 2016

Looks like they have a performance label. I'm sure they'd welcome a merge request.

@sedrubal

This comment has been minimized.

Copy link

sedrubal commented Jan 16, 2016

👍 for gitlab 😄

I think, it's very sad, that almost every open source project uses a closed source git front-end only because of the community and popularity.

And I can confirm that on gitlab it is no problem to get in contact with the developers and they are very focused on the users wishes and requests.

But I'm not sure if gitlab.org would have the capacity to become a "new github"?

@awalgarg

This comment has been minimized.

Copy link

awalgarg commented Jan 16, 2016

But I'm not sure if gitlab.org would have the capacity to become a "new github"?

This is the major point here. Will Gitlab's canonical server be able (now, or in future) to handle the humongous Github userbase?

I am pretty sure if the community here takes the transition a bit seriously and forms even some lightweight tooling to ease things, and a couple major projects set a feat first, transitioning to Gitlab would become a "trend" (for the good, IMO).

Btw, just stating this since it hasn't been already, Gitlab has snippets as the equivalent of github gists :)

@DouweM

This comment has been minimized.

Copy link

DouweM commented Jan 17, 2016

Some weeks ago I experimented with the idea of Varnish/nginx in front of GitLab, primarily to workaround (not to eliminate) some of its performance problem. However, I didn't complete it enough to form an opinion whether the experiment is successful or not.

@ariya In our experience, the performance of GitLab on a private server is good to great, with the exception of some specific endpoints in situations with very large numbers (1000+) of projects per user/group. We are actively working on improving the performance of these in particular and the whole system in general on the Rails side. In normal use however, you should not have any problems with GitLab performance as long as your server meets the system requirements.

GitLab.com is another story, and we are seeing slowness cause by a number of factors, including but not limited to NFS. We are sorry, and are working on improving GitLab.com performance in Q1 2016: https://gitlab.com/gitlab-com/operations/issues

And I can confirm that on gitlab it is no problem to get in contact with the developers and they are very focused on the users wishes and requests.

@sedrubal That's nice to hear, thank you :)

Btw, just stating this since it hasn't been already, Gitlab has snippets as the equivalent of github gists :)

@awalgarg We do! GitLab has snippets, both global and scoped to a particular project.

@DouweM

This comment has been minimized.

Copy link

DouweM commented Jan 18, 2016

People considering GitLab may be interested in our "Dear open source maintainers" letter and the accompanying Hacker News discussion.

@kennetpostigo

This comment has been minimized.

@pvorb

This comment has been minimized.

Copy link

pvorb commented Jan 18, 2016

I am pretty sure if the community here takes the transition a bit seriously and forms even some lightweight tooling to ease things, and a couple major projects set a feat first, transitioning to Gitlab would become a "trend" (for the good, IMO).

@awalgarg Migrating projects to GitLab already is quite convenient. Issues get imported automatically. I'd wait until Jan 22nd, though, when the next release will be published which will also automatically import Pull Requests: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2168

@CWSpear

This comment has been minimized.

Copy link

CWSpear commented Jan 18, 2016

I think the social aspect must be considered as well. Not to say that is not a reason to propose a migration, but as it stands now, "not being GitHub" creates more of a barrier for others to contribute. Just look at all of the projects that have moved from whatever they were using before to GitHub.

I'm not privvy to everyone's thoughts process behind their moves, but I've seen many "move repo to GitHub" issues on BitBucket. And frankly, having worked on large enterprise projects that were both GitHub and BitBucket backed, I've found BitBucket much nicer to work with to do code reviews and such.

But I don't have any large OSS projects on BB, and the dynamics are different, so it may not be a fair comparison.

Anyway, I want to reiterate that I'm not saying a migration isn't the answer, but we also can't deny that as of today, there are benefits of putting the repo for your new awesome OSS project on GitHub over anything else just because "it's GitHub."

@ariya

This comment has been minimized.

Copy link

ariya commented Jan 21, 2016

Migration to GitLab doesn't mean that the code needs to disappear completely on Github. Thanks to the multi remote nature of git, this is entire possible. I can have my FooBar project under gitlab.com/me/foobar and still push it to Github so that it is also available and discoverable through github.com/me/foobar. There are projects that do this to offer an official/unofficial Github mirror.

For contribution and participation, GitLab supports login via Github. Thus, there is no need create a dedicated GitLab account, if one prefers to continue to use Github account.

@pravi

This comment has been minimized.

Copy link

pravi commented Jan 29, 2016

I have been packaging gitlab for debian and they are very supportive to issues that I filed. They are a great project to work with.

Now installing it is just an apt-get away for those who want to setup their own instances https://tracker.debian.org/pkg/gitlab (right now in unstable and I'm working on a jessie backports).

@nafg

This comment has been minimized.

Copy link

nafg commented Feb 10, 2016

Other advantages of gitlab:

  1. Better users/roles system (more intuitive, I think more levels)
  2. Protected branches cannot be pushed by people without requisite permissions
  3. Integrates well with custom issue tracker / custom CI (not to mention their own CI of course)
@sedrubal

This comment has been minimized.

Copy link

sedrubal commented Feb 11, 2016

  • repo icons :)
@connorshea

This comment has been minimized.

Copy link

connorshea commented Feb 17, 2016

GitLab.com is now a lot faster across most of the site, check it out :)

We've got a lot of merged PRs regarding performance recently, and we recently fixed a bug that has improved performance 3x for many pages! We'd love to have you :D

@CWSpear

This comment has been minimized.

Copy link

CWSpear commented Feb 18, 2016

Git operations from the command line are still very slow.

Compare GitHub on the left to GitLab on the right. This is just one simple demonstration, but in my day to day, it seems any pushes/pulls are significantly slower like this example shows:

screen capture on 2016-02-17 at 16-22-04

Using time <command>, we get:

# origin is GitHub
git pull origin master  0.02s user 0.02s system 2% cpu 1.658 total
git pull gitlab master  0.02s user 0.02s system 0% cpu 7.318 total

(GitLab takes approximately 4.4× longer to do a pull on an up-to-date repo)

@pvorb

This comment has been minimized.

Copy link

pvorb commented Feb 18, 2016

The left shows BitBucket.

Cameron Spear notifications@github.com schrieb:

Git operations from the command line are still very slow.

Compare GitHub on the left to GitLab on the right. This is just one simple demonstration, but in my day to day, it seems any pushes/pulls are significantly slower like this example shows:

screen capture on 2016-02-17 at 16-22-04


Reply to this email directly or view it on GitHub:
#56 (comment)

@CWSpear

This comment has been minimized.

Copy link

CWSpear commented Feb 18, 2016

Oh yeah. Forgot I moved that to BitBucket a while back, lol. I'll post another test when I am back at my computer.

@CWSpear

This comment has been minimized.

Copy link

CWSpear commented Feb 18, 2016

Ok, similar results, but for reals, GitHub vs GitLab:

GitHub:

❯❯❯ time git pull origin master
From github.com:CWSpear/local-persist
 * branch            master     -> FETCH_HEAD
Already up-to-date.
git pull origin master  0.02s user 0.04s system 4% cpu 1.396 total

GitLab:

❯❯❯ time git pull gitlab master
From gitlab.com:CWSpear/local-persist
 * branch            master     -> FETCH_HEAD
Already up-to-date.
git pull gitlab master  0.02s user 0.02s system 0% cpu 6.837 total
@elygre

This comment has been minimized.

Copy link

elygre commented Feb 26, 2016

One thing worth checking is which protocol you use. On GitLab, ssh is seriously slower than https, as shown below (two runs per test):

  • https from github: 0.921 and 1.046 -> avg 1-ish
  • https from gitlab: 1.846 and 1.230 -> avg 1.5-ish
  • ssh from github: 2.050 and 2.043 -> avg 2-ish
  • ssh from gitlab: 4.901 and 6.665 -> avg 5.8-ish

Full test:

[tmp]$ time git clone https://github.com/CWSpear/local-persist.git lphttps1
Cloning into 'lphttps1'...
remote: Counting objects: 171, done.
remote: Compressing objects: 100% (57/57), done.
remote: Total 171 (delta 28), reused 0 (delta 0), pack-reused 114
Receiving objects: 100% (171/171), 33.33 KiB | 0 bytes/s, done.
Resolving deltas: 100% (70/70), done.
Checking connectivity... done.

real    0m0.921s
user    0m0.090s
sys     0m0.086s

[tmp]$ time git clone https://github.com/CWSpear/local-persist.git lphttps2
Cloning into 'lphttps2'...
remote: Counting objects: 171, done.
remote: Compressing objects: 100% (57/57), done.
remote: Total 171 (delta 28), reused 0 (delta 0), pack-reused 114
Receiving objects: 100% (171/171), 33.33 KiB | 0 bytes/s, done.
Resolving deltas: 100% (70/70), done.
Checking connectivity... done.

real    0m1.046s
user    0m0.085s
sys     0m0.092s

[tmp]$ time git clone git@github.com:CWSpear/local-persist.git git1
Cloning into 'git1'...
remote: Counting objects: 171, done.
remote: Compressing objects: 100% (57/57), done.
remote: Total 171 (delta 28), reused 0 (delta 0), pack-reused 114
Receiving objects: 100% (171/171), 33.33 KiB | 0 bytes/s, done.
Resolving deltas: 100% (70/70), done.
Checking connectivity... done.

real    0m2.050s
user    0m0.019s
sys     0m0.033s

[tmp]$ time git clone git@github.com:CWSpear/local-persist.git git2
Cloning into 'git2'...
remote: Counting objects: 171, done.
remote: Compressing objects: 100% (57/57), done.
remote: Total 171 (delta 28), reused 0 (delta 0), pack-reused 114
Receiving objects: 100% (171/171), 33.33 KiB | 0 bytes/s, done.
Resolving deltas: 100% (70/70), done.
Checking connectivity... done.

real    0m2.043s
user    0m0.024s
sys     0m0.027s

[tmp]$ time git clone https://gitlab.com/elygre/lpclone.git glh1
Cloning into 'glh1'...
remote: Counting objects: 171, done.
remote: Compressing objects: 100% (91/91), done.
remote: Total 171 (delta 70), reused 171 (delta 70)
Receiving objects: 100% (171/171), 33.33 KiB | 0 bytes/s, done.
Resolving deltas: 100% (70/70), done.
Checking connectivity... done.

real    0m1.846s
user    0m0.090s
sys     0m0.096s

[tmp]$ time git clone https://gitlab.com/elygre/lpclone.git glh2
Cloning into 'glh2'...
remote: Counting objects: 171, done.
remote: Compressing objects: 100% (91/91), done.
remote: Total 171 (delta 70), reused 171 (delta 70)
Receiving objects: 100% (171/171), 33.33 KiB | 0 bytes/s, done.
Resolving deltas: 100% (70/70), done.
Checking connectivity... done.

real    0m1.230s
user    0m0.094s
sys     0m0.074s

[tmp]$ time git clone git@gitlab.com:elygre/lpclone.git gls1
Cloning into 'gls1'...
remote: Counting objects: 171, done.
remote: Compressing objects: 100% (91/91), done.
remote: Total 171 (delta 70), reused 171 (delta 70)
Receiving objects: 100% (171/171), 33.33 KiB | 0 bytes/s, done.
Resolving deltas: 100% (70/70), done.
Checking connectivity... done.

real    0m4.901s
user    0m0.015s
sys     0m0.031s

[tmp]$ time git clone git@gitlab.com:elygre/lpclone.git gls2
Cloning into 'gls2'...
remote: Counting objects: 171, done.
remote: Compressing objects: 100% (91/91), done.
remote: Total 171 (delta 70), reused 171 (delta 70)
Receiving objects: 100% (171/171), 33.33 KiB | 0 bytes/s, done.
Resolving deltas: 100% (70/70), done.
Checking connectivity... done.

real    0m6.665s
user    0m0.012s
sys     0m0.035s

They are aware of this one, though: https://gitlab.com/gitlab-com/operations/issues/99

@chadwhitacre chadwhitacre referenced this issue Mar 11, 2016

Closed

Radar 49 #532

@eddieajau

This comment has been minimized.

Copy link

eddieajau commented Jul 28, 2016

I've been using GitLab for over a year now and while a year ago it really was the wild west, slow, ugly, etc, a lot has changed since. The main sellers for us at work are:

  • Unlimited private repositories are free.
  • Includes a CI so for the most part you can eliminate Jenkins and Travis to do your builds
  • Raising issues about GitLab are open and transparent.

I would say the main difference is GitHub is designed for people who want to collaborate on writing software, but that's where it stops. GitLab is designed for people to collaborate and take that software right through to build and deployment.

It's brilliant!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment