Moving to GitLab: Yes, it's worth it | Hacker News Reader

Moving to GitLab: Yes, it's worth it

about.gitlab.com

292 pointsbrodock346 comments

As I always say on every GitLab post on HN (and no I'm not paid to nor do I have any affiliation with the company) - we switched from a combination of Github + Gitolite/Gitosis to GitLab not long after it was release and my god it's damn good, It's really impressed us particularly in the last 12 months how rapidly they're developing the product and getting new released / fixed / features out. Especially like Gitlab CI w/ Docker.

Thanks, always great to see you here!

I really liked Gitlab when last I tried it, but in the end I went with https://gogs.io/ instead. For a small-ish team this felt like the most straight forward self-hosted solution. Still missing LFS though, which sucks, but it's being worked on.

We've been using https://rhodecode.com for internal repositories: it is also open source, yet has better interface and out-of-the-box LFS support.

The native subversion and mercurial support for the same repos is incredibly attractive. Any idea how it converts them to a shared format in real-time?

@mc42 They use a common layer called "VCS server". Here's how it looks like from the system architecture standpoint: https://docs.rhodecode.com/RhodeCode-Enterprise/admin/system...

Thanks, that's really cool.

Does it have repo mirroring? One of my favorite features of Gogs is the ability to mirror a remote repository with automatic updates.

Can't recommend gogs enough, slick/simple yet quite fast. Hassle free installation is a bonus.

We recommend Gogs for people that want to run on machines with little memory, it's great.

Yeah it runs great on an rPi. I doubt you can say that about Gitlab or RhodeCode.

I wish GitLab could be a bit lighter weight as well. I'd love to spin up the cheapest VM instance I can find on a cloud provider, pull a Docker container, and have a working GitLab instance up and running, but they "strongly advise against" running GitLab at the amount of memory those cheap VMs usually come with (usually around 512MB) [1].

[1] https://github.com/gitlabhq/gitlabhq/blob/master/doc/install...

gogs is pretty slow as soon as your repository gets bigger. At least when I last tested and contributed to it a few months ago. IIRC gogs parses the whole "last commit to this file or directory" before sending the response which is pretty slow.

I am using LFS on GitLab right now, works perfectly and I mention it in the article.

I couldn't help noticing Gogs is hosted on GitHub...

  https://github.com/gogits/gogs

I don't know how to feel about that, on the one hand it's "not using the soap you're selling" and makes you seem disingenuous about the quality of your product.

However, it is the "home of developers" right now, and they probably would prefer a low barrier to entry for people to get involved.

Many large (or aspiring) open-source projects seek to create a community of users around it, and having a lower barrier of entry to create such a community only helps the project. As you've said, GitHub provides such a low barrier.

GitLab also started out on GitHub didn't it?

Yes we did. And we still have a non-canonical mirror there https://github.com/gitlabhq/gitlabhq#canonical-source

I totally understand why people host open source projects on GitHub.com, most open source developers have accounts there so it lowers the barrier to contributing.

BTW If you host it on GitLab.com people can login with their GitHub account.

Last time our team tried gogs, it is unusable. Some very important features are missing:

- code review

- deployment key

And the builtin SSH server will randomly hang once or twice every day.

Gogs has had both those for quite some time now.

We did a comprehensive internal review of both gogs and gitlab. Gogs was a long way ahead of gitlab in terms of stability/speed and had pretty much all of the features developers tend to need.

Can we comment on a specific line in a merge request with gogs now?

Wow, that UI is VERY similar to github: https://try.gogs.io/sigf/test

Interestingly, some of those features were introduced by gogs first, and then appeared at GitHub - like the tabs on top.

GitHub had tabs at the top, redesigned to use a sidebar, then went back to tabs at the top, I believe.

FWIW once you get past the initial install, updating GitLab with each release is very smooth.

Working for a 15-year old small software company, I converted a whole bunch of ancient CVS stuff (yeah, yeah, don't laugh unless you also have 15 years of profitability) to GitLab CE. After a couple of false starts it went flawlessly and now works flawlessly.

(I used the tigris.org migration tools).

The GitLab team is doing a great job. Thanks you guys.

Thanks Oliver, that's great to hear.

Any way we can prevent those false starts for other people?

The false starts in our conversion were mostly struggles with how to restructure our old CVS repos so they made sense in the world of git. A few of them had to do with capturing some oddball CVS specific revision and branching history.

None of the false starts were due to flaws or confusion in GitLab specifically.

I should, and if you pester me I will, sanitize our internal how-to documents and scripts and contribute them to the Gitlab community so the next guy can benefit from our experience.

Pesters!

It would be great to receive some contributions to our documentation. It has proven a big challenge to make sure it covers everything and stays up to date. We'd really appreciate it.

How about 20+ years of operational history from SCCS: http://fanf.livejournal.com/132656.html

One of the most successful companies I worked at had no version control or unit tests whatsoever. The code was all maintained by one person (the company relied heavily on custom software internally but it wasn't their product), who was able to keep the codebase small enough to basically hold in his head the whole time despite generating millions of dollars of value.

That's certainly not how I would write code today, but it is amazing to see how much top-notch programmers vary.

I was pretty impressed with how easy it was to get free CI runs on pushes and merge requests with my OSS game: https://gitlab.com/technomancy/bussard/commit/73e84d11ed33ff...

This made GitLab hosted repos well worth it for me over github or bitbucket:

https://about.gitlab.com/gitlab-ci/

We recently launched pipelines, it is in beta right now: https://bitbucket.org/product/features/pipelines

We're working hard on making CI super easy to use and setup.

If you want to give it a spin, check out our recent blog post on starting from 0: https://about.gitlab.com/2016/07/29/the-basics-of-gitlab-ci/

I was trying to look into Gitlab Runner the other day. How decoupled is it from Gitlab itself? Would I be able to somewhat easily write a completely different UI, with a different framework/language (say, Django), hook it all up to Github/Gogs and use Gitlab runner for the jobs themselves?

Because if that's what it is, that is pretty kickass.

AFAIK you would not be able to do that. I've asked the author of Runner to comment here.

The Runner interfaces with GitLab through a pretty simple API, so you could do that.

One caveat is that we might introduce a new API by releasing a new version of GitLab and GitLab Runner at the same time, then you would need to upgrade you project to stay compatible.

BTW To ensure nobody is confused, you can use GitLab Runner to test all kinds of projects on all kinds of hardware. We're discussing developing an alternative to GitLab but reusing GitLab Runner.

Im using Jenkins right now to basically handle docker deployments. Without taking the time to actually read up on it in depth, does GitLab CI handle ways for me to essentially just pull prebuilt images and run them on a targeted server with desired settings? I'm already preparing to move to GitLab CI for images that I build myself (since Im already storing the Dockerfiles on gitlab)

Yes, using prebuilt images is easy. Basically, just add `image: ruby:2.3.1-alpine` to a job, for example.

Docs: http://docs.gitlab.com/ce/ci/docker/using_docker_images.html...

That seems to be referring to using docker images as part of the build process.

Im referring to using docker images as the deliverable. I mostly want to just have a gui to do "docker pull x" "docker stop xcon && docker rm xcon" "docker run --name xcon -v /volumes/x/config:/var/www/config -p 8080:80 x" for me. There would technically be nothing to be stored in the gitlab repo here, except the config.

Replace the "docker pull x" step with docker build in the event that I'm using a dockerfile to build a custom image, which could trigger as a result of updating the dockerfile... but usually the dockerfile doesnt change, it just needs to be re-run to pull in upstream changes.

Thanks for clarifying. I'm pretty sure you can do everything you want here. You could install a runner on your production box and run those commands within a deploy job.

Two options for configuring the runner:

1: http://docs.gitlab.com/ce/ci/docker/using_docker_build.html#...

2: http://docs.gitlab.com/ce/ci/docker/using_docker_build.html#...

Thanks, this looks like it describes my use case exactly. I'll have to read into this more!

In case you would like to shave a couple of seconds off per build, you might want to build a docker image with both luarocks and love already installed.

This would also be a great reason to test the awesome GitLab Docker Registry[1], which is also included in CE!

[1] http://docs.gitlab.com/ce/container_registry/README.html

Very interesting! I remember trying your game a few months back, but I didn't have the time to really get into it.

I was thinking about making a game in Löve for a while now, but I have never done any automated testing with it.

Is there a good tutorial for that? Or do you feel like writing one? ;)

I highly recommend using Löve; the simplicity is very compelling.

I wrote a bit about testing on my blog, but it's more about the architecture of how the user-input system meshes with the internal reprogrammability. There's a bit about fuzz testing though: https://technomancy.us/180

Maybe I'll follow it up with a more detailed post specifically about automated testing in Löve since it seems to be not well-understood.

Thanks for the link. More information about testing with Löve (heh, "with Love") would be wonderful, I'm only used to Enterprise Java, I'm afraid.

We also have xonotic on GitLab, it's quite awesome :)

Would love to hear your thoughts on developing a game using GitLab, anything we can improve in that regard?

[1]: https://gitlab.com/xonotic/xonotic

Well, unfortunately I don't have many contributors yet, so I can't speak much to the collaboration features. The only thing I can think of is that it would be nice if it were easier to get CI failures announced in Freenode channels. I haven't looked into it in a while, but last I checked it was a bit tricky to hook up push events into IRC.

All the minor complaints I had a while back have been addressed (not showing the readme as the splash page, and not being able to reply to issue emails) so I've been quite happy with it.

I also appreciate how force-pushes to master are disabled by default. The fact that my browser's Emacs key bindings don't get stolen by the issue textarea to do stupid markdown stuff is very much appreciated. (glares fiercely at github)

I was pretty impressed how easy it was for me (a server newb) to setup my own GitLab CI on a AWS server. For my projects now it takes around 15 seconds from when I push to GitLab for it to be deployed.

I love how responsive our local (departmental) instance of GitLab CE is -- it's downright snappy compared to the corporate instance of JIRA. We love the issue tracking subsystem of GitLab and use it as our main ticketing system.

We've done a few talks on Git basics to help increase adoption, and are doing a free webinar "Git Foundations: Basic Concepts and Definitions" next week: https://www.eventbrite.com/e/git-foundations-basic-concepts-...

This is the sort of result it makes us very happy to achieve:

"I have got by on minimum understanding of Git for a couple of years now--this really brought up my confidence in using Git. After I learned the Git internals, the esoteric commands really started falling into place." --Nicholas Santucci, Monitoring and Performance Engineer

That's some great feedback, thanks! Any feature requests for Issues?

If you plan on doing physical events, drop me an email (job at gitlab).

We've done three physical events already. :-) I'll email you! Our next physical event will be teaching at Ohio Linux Fest (https://ohiolinux.org/olfi/)

Feature requests for Issues: priorities, and states other than open and closed. These are the biggest things keeping us from using GitLab issues rather than an external tool.

We need to be able to set priorities (ideally customizable, but at minimum high/med/low). We can kind of do that through labels, but it's messy because you can only search for one label at a time (no boolean combinations of labels).

Right now, when you assign an issue to a user, it's considered "in progress", and from there it can either be unassigned or closed. It would be nice to separate the state of the issue from the assigned user, since in our current workflow we assign many issues to a user, but that user might only be working on a few of them at a time. Using our current bug tracker, we can differentiate between "Open, unassigned", "Open, assigned", "Open, in progress", "Fixed", "Verified", "Closed", etc. I know having a completely customizable state diagram for issues is a big software task, but maybe there is some intermediary level of complexity that would allow better tracking of what is actually being worked on now vs. what is assigned to people.

Actually you can add priorities to labels :) http://docs.gitlab.com/ce/user/project/labels.html#prioritiz... You can also search for several labels in the current release. Just select some in the dropdown :)

Wow. The power of HN. We did our webinar today and had attendees from the Netherlands, Germany, Serbia and the US. It was exciting to have an international audience.

I've moved from BitBucket to GitLab and on the whole it works well. I still use GitHub for open source projects though.

One problem is that a lot of things automatically work with BitBucket and GitHub but GitLab need manual setup. For example, TeamCity has out-of-the-box support for both BitBucket and GitHub but you have to set up GitLab as a raw git repository (and create a user for it etc.).

edit: I should add that I've also used GitHub professionally with private repositories. However, I quite like having separate credentials for open source vs. more sensitive work.

Is there anything we can do from our side? We're very interested in making it easier to integrate with GitLab, but also happy to invest some time into making existing integrations easier to set up.

Our hope is that with time, it'll become obvious that when developing an application, you integrate with GitLab as well as with BB and GH.

> Is there anything we can do from our side

Addressing this issue will go a long way, in making it easier for others to create solutions that can easily integrate with GitLab.

https://gitlab.com/gitlab-org/gitlab-ce/issues/20567

Great, thanks.

For the upcoming release (8.11, August 22nd), we're adding deploy keys with push permissions [0]. This would allow you to basically do the same thing.

That said, that doesn't make it very clear that you can use these for this purpose, so I've added a note to re-evaluate these.

We're also expanding OAuth scopes, potentially making it easier / more attractive to integrate [1].

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/1376

[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/20492

Since I have your attention, something else that I think should be on your radar is creating/defining supported injection points in GitLab's UI. If you haven't done so, you should look at what Microsoft has done with Visual Studio Team Services.

By providing supported injection points in GitLab's UI, GitLab will be able to signal to others, that they are a solution you can safely build on top of.

That's a very interesting idea.

Right now, to integrate deeply, you'd have to go through the heavy-handed process of creating a service [0]. That then does allow you to do almost anything, but the barrier to entry for that is high.

I created an issue for your proposal and hope you can provide some more feedback on how this would work, ideally [1].

[0]: http://docs.gitlab.com/ce/project_services/project_services.... Services

[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/20667

I'm constantly impressed by how involved GitLab engineers are not just on HN but other communities when brought up. Not sure if you guys have people constantly looking for mention of "GitLab" but even if you are, the responsiveness and agreeableness to look into issues and invite people to be a part of the solution they seek out are phenomenal habits and I applaud you guys for it. It's one of the many reasons I converted a while back from Github and probably wont be looking back anytime soon.

Thanks! Glad to hear that. I wish all companies would be responsive and easy to talk with. We do our best to be both.

> Not sure if you guys have people constantly looking for mention of "GitLab"

We do! Channels straight into chat.

This is great to hear and I personally think this the next battle front for gaining/retaining Git users in Enterprise. I'm currently working on integrating with Bitbucket and Microsoft, and I'll comment on the issue in a few weeks and provide some feedback.

Maybe create a plugin for Visual Studio, like GitHub does. Also try to work with JetBrains to make their GitHub plugin work with GitLab? The GitHub plugin is available during installation, both with Visual Studio and JetBrains products, which makes it much more convenient to use. Things like creating a gist from code in IntelliJ or PyCharm also work out of the box with github.

We're looking into both options, but don't have internal knowledge or capacity to build this ourselves at the moment.

There are some plugins listed here [0], but we hope to have official plugins in the future.

[0]: https://about.gitlab.com/applications

We're exploring the VisualStudio option but as Job said we currently don't have the knowledge to make that happen. I've logged an issue for this request https://gitlab.com/gitlab-org/gitlab-ce/issues/20686 you can back it and follow it there.

As for JetBrains, we discussed this option with them - it would help if you create an issue for that on their platform as a user request to surface it. The more demand their users will have for this request the more likely it is to happen.

Phabricator is a great alternative, by the way. Really stable and has the best code review interface / workflow I've ever used.

+1 for phabricator

I really want to love phabricator, but the local install for a new team is so painful... any thoughts about how to make that better?

I have this problem too. It's not hard to set up, there are just so many tiny pieces that need to be run by hand that it's going to take a human well over an hour to read through the docs and get it right.

Someone made a Saltstack state[1] that I've used and had some success with - installing and configuring Salt from zero and using this config is still faster than installing Phabricator by hand.

[1]: https://github.com/bougie/salt-phabricator-formula

It's actually much easier to setup and operate than GitLab with its massive dependencies.

Also a lot faster.

Gitlab is unfortunately a pig, in the large and bloated sense of the term. Which is really sad! I love the app, it looks better than Phabricator and does so much more, but then I can throw Phabricator on the same droplet I use for plenty of other stuff with resources to spare for $5/month, where Gitlab would require a dedicated $10 instance just due to memory usage alone.

Guess I'm just not the target audience :(

You can use gitlab.com for free... don't need to install it in your own box.

Setting up GitLab can be done through our repositories quite easily nowadays. It boils down to: apt-get install gitlab-ce

I'm talking specifically about the client tool arcanist, which IMO is the real benefit of Phabricator

Everyone is talking about installing these services. Don't they have a central hosted server like Gihub?

Package it as a docker container.

If only phab didn't insist on squashing a patchset into a phabricator-commit, losing the carefully created history of a branch. Cumulative mega-patches are of little use when bisecting or trying to understand how a change works by being able to follow the steps to reach the final diff. A good commit history with separate commit messages explaining the diffs goes much further in allowing someone else to understand a change than any code comment could. This is also why merge commits are useful, because they allow you to group the commits for a feature branch and not miss any of the commits involved.

Phabricator could easily include their metadata in a merge commit, instead of collapsing the branch into one mega-commit. I know some people love a flat history without merge commits, but those lose a lot of info available with a graph/tree visible when there are no forward merges.

You can disable the squashing. It's a common complaint.

https://secure.phabricator.com/book/phabricator/article/arca...

> Phabricator could easily include their metadata in a merge commit

And this is what happens :-)

Thanks for the link. As arcanist is the php-based client to speak to Phab, does this mean it's a user setting only and is fully respected by Phab, meaning it's something set on first publishing of a diff and kept in that setting? Is this also possible when submitting a diff via the web interface?

What's funny is that mutability didn't exist for Mercurial support because when it was written Mercurial had no official mutability feature.

And I can only suppose mutability being default for git support is because of Facebook's dev style. It's wrong to assume that those who want merge commits for the final merge onto master do not rebase locally before sending a pull request. Rebase is a standard tool for working on your branch (aka patch set aka patch queue) and it's normal to rewrite it upon each revision of the branch sent for review. Does phab support multiple revisions of a branch in one diff or does it require separate diff tickets? This is something that Gerrit got right, allowing one to see the diff between revisions of a branch (patchset).

Have not used them, but I really appreciate how their copy is written to appeal to devs. Ex:

    Customizable Task Management

    Plan features, track bugs, and award tokens. Maniphest lets you customize input forms, use custom fields, and has a rich API.

    Keeps track of lots of bugs.
    You can assign them to people.
    Maybe you could fix them, eventually. (optional)
    Build unique task forms for every department.
    For example, look at this feature in Phabricator itself: T6526

    Business Rules

    As your company scales, keep track of activity with Herald, which notifies you when things you care about happen (like a specific file being changed).

    Write business rules.
    Everyone loves business rules.
    Keep an eye on suspicious new hires.
    Warns you about plotting and scheming.
    Build triggers on tasks, commits, revisions, and more.

I posted before[0] about why I moved to gitlab; I'm using a self-hosted instance and the only real complaint I have is resource consumption. But if you bite the bullet a bit it's a really great product.

The other thing would be "ease of deployment" or lack thereof- if you're going for anything other than omnibus installs or docker images then it can be a bit painful. (I wanted to run on freebsd for example).

But, yes, it's super nice to have something not only comparable to github but even superior in some areas. I would definitely run the enterprise edition if that were my decision at work.

[0]: https://libsecure.so/t/github-alternative-aka-weve-moved-git...

Similar view for myself; though the resource consumption is such a minor complaint that I don't even really consider it relative to all of the benefits GitLab provides.

How has your experience of installing gitlab on freebsd been? Anything in particular that can be improved? I'm pretty sure the gitlab team is open for all kind of improvements. :)

Someone wrote a very nice and detailed guide, however upgrading isn't mentioned[0]

it also suggests operating under bad practices like running gitlab from /home/

I guess I could write a decent salt-formula to do all this, but I can't handle upgrading of gitlab easily, it always breaks when I take a new branch from git and run a gitlab-ctl reconfigure.

[0]: https://github.com/gitlabhq/gitlab-recipes/blob/master/insta...

The pkg-message of the Gitlab port has some useful links to more documentation.

https://www.freshports.org/www/gitlab/

https://github.com/t-zuehlsdorff/gitlabhq/blob/master/doc/in...

https://github.com/t-zuehlsdorff/gitlabhq/blob/master/doc/up...

Last time I tried Gitlab, I changed the setting to allow more than 10 projects for each user but the changes never took place. So I stuck with Gogs which is much much faster anyway.

As always, we're happy to answer any questions about GitLab.

Why doesn't LFS support SSH authentication? It has been requested numerous times and has missed numerous milestones. I'm still not convinced it will hit 8.11. We desperately need LFS support, but we use one time tokens, so LFS Authentication over HTTPS just won't work for us. We are an EE customer and this future is way more useful than a UI redesign! https://gitlab.com/gitlab-org/gitlab-ce/issues/3589

We're planning to do this as soon as possible. I agree that it has taken a long time. We simply did not have the capacity with the people that are able to work on this, to build it earlier.

We now have strengthened the team that works on these issues. I'm seeing whether it's possible to ship this with 8.12 (due Sept 22nd).

Git-LFS is a github project, you'd be better off asking them. But yeah I share your exp. without SSH and with all its numerous bugs LFS is one of the worst pieces of software i've come across. We switched to using rsync for binaries/ large files etc.

Any ideas of supporting Mercurial, too?

We're not planning to support Mercurial in the near future.

For Mercurial check out RhodeCode which is also supporting some of unique Mercurial features like largefiles, phases, bookmarks.

Just to give you guys some credit: I've had the pleasure of working with RhodeCode on my previous job 2.5 years ago and it was an awesome experience. HG & Git support, full-text search, repo-specific access control, a nice gui, easy setup, etc. Unfortunately, most devs and sysadmins I talk to don't even know about your product, which is a real pity, as they all use the same inferior products and don't know what they are missing out on. Now i'm stuck with gitlab and bitbucket-server, which everyone thinks are great, but every time I log into them I silently cry out for rhodecode. Hope you guys are doing well.

Can you give any specific feedback about Bitbucket Server? What can we do better?

Anything specific we can do at GitLab so you don't feel that way when using it?

@dvdgsng We're better than ever, thanks! I don't know if you heard, RhodeCode CE is now free and open source. Feel free to join our Slack: https://rhodecode.com/join

We'll be rolling out a major release next week, might be the right time to spread a word to colleagues ;)

Heroku offers automatic deploy on linked repos from GitHub. Do you plan to integrate with Heroku to offer similar feature?

I believe the ball lays with Heroku for this one, mostly, but we'd love to see that in GitLab of course.

However, you can already deploy from GitLab quite easily to Heroku, it just requires a single line in your CI config:

http://docs.gitlab.com/ce/ci/examples/test-and-deploy-ruby-a...

And with Heroku's beta support for Docker deployments, it's even easier.

Any hope to get improvements on the issue tracker?

We hope to ship Issue boards[1] this months, which will be a mayor improvement! But maybe you could be more specific to what you're missing? We'd love to hear your feedback!

[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/17907

Issue boards is great, but this is far from what we would need, tbh. We need a bugtracker, not a scrum board.

Mostly, we need a way to defined custom fields to be able to triage, query and reassign automatically. Like for example components or platform. And labels are clearly not enough for that.

I feel as though some of the recent UI changes were cosmetic and degraded the experience. I was especially unhappy about the sidebar being pushed into a hamburger menu (which can be pinned open, mind you).

I'd really like for UI updates in the future not to be jarring and seemingly pointless. I really liked the UI right before the overhaul, only minor tweaks seemed truly necessary. Many of the tweaks I would have suggested before have come through; such as putting profile information and notifications in the upper right hand corner. I'm glad about that.

Other than that; I'd like to say that I have really liked using Pivotal Tracker for developing software. It has a rigid pipeline between requirements and results. Configurability ruins some productivity tools. It would be swell to have something like "Pivotal Tracker lite" associated with GitLab (in that GitLab CI is). It's not a difficult kind of software to do reasonably well, and it would make GitLab the ultimate software project productivity suite.

I've asked some people that work on our UI to respond, but we're aware that we have some ways to go before it's really good and that the large changes that we're making can be painful at first.

> Other than that; I'd like to say that I have really liked using Pivotal Tracker for developing software. It has a rigid pipeline between requirements and results. Configurability ruins some productivity tools. It would be swell to have something like "Pivotal Tracker lite" associated with GitLab (in that GitLab CI is). It's not a difficult kind of software to do reasonably well, and it would make GitLab the ultimate software project productivity suite.

Could you elaborate on what kind of features we'd be required to add given your suggestion? What do we miss?

Thanks for your feedback - we are always working on improving the UX/UI and appreciate your input! I know that large changes can feel jarring at first but we hope that in the end, they help improve workflow and productivity.

The sidebar is a global navigation and not always necessary when interacting with page-specific content on the site. GitLab is very content heavy and by allowing the sidebar to be collapsed, it allows users to have more space on smaller screens to read/scan the information that they need. As you mentioned, the sidebar can be pinned so users can view the navigation all the time if they prefer, esp if they are using a larger screen.

If you have other examples of changes that you felt were pointless, I'd love to find out the reason for the change for you!

I also urge you to voice your opinion by making an issue for changes that you think would help improve the user experience. https://gitlab.com/gitlab-org/gitlab-ce/issues/new

Was over a year since I last used GitLab, and I wonder if the resource usage and response times of a self-hosted instance has improved? Back then we were 3 developers having roughly 20 repos. The memory usage was over 2GB when idle and response times were at best between 2-3 seconds.

Testing your hosted version, loading this page[1] for example takes 4 seconds (3.6s TTFB). Don't get me wrong, the platform and its features are very broad and very good, but I personally can't stand having such long loading times. It's very frustrating because I really want to use GitLab and its features.

My feedback would be to set a main focus on reducing the TTFB for the Web UI, but also the Git server, because it takes a couple of seconds for it to respond to pushes.

[1] https://gitlab.com/gitlab-org/gitlab-ce/commits/master

They've done a lot of work on performance in the past year. I'd recommend taking it for another spin.

Not enough, apparently. That page takes 10.5s to load and fails several performance metrics.

https://tools.pingdom.com/#!/cOKg2F/https://gitlab.com/gitla...

See my comment above, but in short: GitLab.com is not representative of a self-hosted GitLab instance.

GitLab.com is too slow. We're working on it here: https://gitlab.com/gitlab-com/infrastructure/issues/59

I get 5.5s now when I re-run it (probably due to caching). We've been working incredibly hard to make it faster, we have to use it everyday, so we know exactly how annoying the lack of speed can be.

For example, take a look at the drop in response time in the middle of last month: http://stats.pingdom.com/81vpf8jyr1h9/1902794/2016/07

We've focused on speeding up some more common pages (Issues, MRs, etc.), but still a ways to go for the rest of the application!

Ceph should make a big difference once we get GitLab.com running on it in a few months, the reason the commits page specifically is so slow is because our current infrastructure is bottlenecked by filesystem-heavy interactions (e.g. getting all the recent git commits for a repository).

Ceph issues are here: https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...

If you run your own instance of GitLab now, it will be fast. Since last year March we've grown from 9 to now 100 people, many of which dedicated to performance.

GitLab.com is slow, occasionally painfully so. We're very aware of that and are working to improve that. You're welcome to watch or contribute here [0].

[0]: https://gitlab.com/gitlab-com/infrastructure/issues/59

I just finished an evaluation of Gitlab for our company and I'm blown away by all the awesome little touches that are geared toward productivity (merge requests that can be merged to a second branch with two clicks? yes please!).

That said, I'm holding off for now because I'd love for it to replace both Github and our current ticketing system, and rather than doing two migrations, I'd rather wait a few months until you guys have fleshed that out and do it all at once. The issue boards on your roadmap look absolutely fantastic, but the true killer feature I'm waiting on is time tracking, which I'm hoping makes it in later this year. Get that in and I think you'll see people flock to Gitlab.

In that case you might want to track issues on the velocity analytics

- https://gitlab.com/gitlab-org/gitlab-ce/issues/18687 - https://gitlab.com/gitlab-org/gitlab-ce/issues/20608

If you have ideas to improve the current vision, don't hesitate to join the conversation!

Why do you offer hosted EE gitlab free? I mean I love it but that seems to run counter to keeping gitlab around. In fact there seems to be no way at all to pay for gitlab, without having to host a local install.

Most of the market revenue is concentrated in on-premises/single-tenant installations, also see https://about.gitlab.com/gitlab-com/#why-gitlab-com-will-be-...

You can always use our hosted private GitLab service[1] if you really insist on giving us your money without the hassle of a local install :)

[1]: https://githost.io/

Is there any reason why Gitlab is not adding mercurial support? Git command line is a nightmare to work with.

I'm recently setup Gitlab for my personal projects, import from bitbucket was a breeze.

I've used omnibus installer and it was almost painless, only a couple of issues because of LXC limits.

My only concern is resource usage, it does take at least 2Gb memory, are there any options to tweak it?

We do recommend you allocate resources generously, with 2Gb minimum.

That said, there are ways to tweak it. I believe you can reduce the default amount of Unicorn workers to one, as a start. Further than that I'm out of my league; I'll ask one of our awesome service engineers to respond here.

Also, please lower the default number of unicorn workers from 3 to 2.

We are in the middle of migrating from Bitbucket to our self hosted CE version and apart from a few permissions issues on SSH keys we have had no issues with the whole process and updating our deployment system was just a case of changing git urls.

Well done Gitlab :)

Thanks Mark!

The idea of switching from one company that holds your data to another doesn't make sense to me. What does make sense and is worth working for is being able to host my own code on my network. That's where GitLab really comes in for my work. I have no reason to switch from one platform to another if I can't host it in my own network.

GitLab was a great idea but from my experience it's been built on an extremely frustrating method of deployment.

I'm not a dev ops person nor do I want to be. I want things to be as simple as "run this and it will work" without me needing to do much of anything.

I tried to setup a GitLabs instance but after running a simple update command (apt-get update && apt-get upgrade) it broke. It seemed to have something to do with something called Sidekick at the time or something along those lines. It was just frustrating that the automated update scripts from their deb BROKE their own system. That just should never be a possibility in a system, I have near no tolerance for dealing with crap like that.

After messing around with it for a while I gave up and tried Gogs. It was easier to use but using go's build tools yielded similar problem for me. It's not the easiest thing to setup and takes a bit of know how to get Gogs and golang's build tools working (I know someone is going to tell me I'm wrong and that this did not happen to me).

I settled on GitBucket [1] and I have to say I'll not be switching to anything else. It was simple: download and run a single jar file. I setup an unprivileged user, it's own opt folder, and a small init.d script to do everything I needed. To update I download the latest version and I do a drop in replacement with the .jar. Nothing difficult. (Sadly GitHub seems to have put legal pressure on them to change their 'look' so they've done that but before that it was perfectly stable in appearance unlike GitLabs).

If anyone is interested in the self-hosting aspect of this, I'd say don't look at GitLabs, Gogs, or any of the other systems out there. Look at GitBucket.

[1] - https://gitbucket.github.io/

I'm surprised you're not running the docker instance, it's literally "run this and it will work" in fact, most of their instructions are rather on the nose.

Getting docker working for me has always been a pain. I've still not gotten as docker install working across updates or dist-upgrades.

Again, I'm as much of a sysadmin/debops is a neurologist in the way that I'm in no way a neurologist. If I cut open someones head, maybe messed around with some things, and closed it up they might be ok. That's how my servers 'run'.

Anything outside securing the system (ssh key auth, non-root user, etc) to a standard good enough for me is not doable.

We moved from BitBucket on premise to GitLab CE on premise. Actually most things now just works. Updating is a breeze. Instead of downloading a installer and copying / fixing server.xml we can just do a apt update && apt upgrade -y.

Some things are a little bit akward but BitBucket didn't had this, too:

- FF only merges is only EE (too bad that would be a really major selling point even for CE, squash button would be unnecessary)

- CI is a little limited compared to a full blown Jenkins - We hit a CI bug which still shows up "Running" Pipelines https://gitlab.com/gitlab-org/gitlab-ce/issues/19455

- Artifacts API is limited to everything or nothing

- CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw)

- No Custom CSS (yeah our logo isn't 72px x 72px...)

But then again BitBucket didn't had these things anyway so except the bug it's nothing that would've hold us back. Everytime you wanted a Feature for BitBucket, the guys said that there is/was an extension. How dare that costed a shitload of money which would even superseeded GitLab EE.

Thank you for the awesome detailed feedback. Responded point by point below:

> FF only merges is only EE (too bad that would be a really major selling point even for CE, squash button would be unnecessary)

These are always hard choices to make for us. We wrote about these decisions here [0].

> CI is a little limited compared to a full blown Jenkins - We hit a CI bug which still shows up "Running" Pipelines

We're still young, but confident that we'll get there! CI/CD is a major focus for us and we're working really hard to improve it with every release. Love to get specific feature requests for things that we miss in comparison with Jenkins.

Regarding the bug: I've pinged our PM on it.

> Artifacts API is limited to everything or nothing

Could you elaborate? I know we have numerous improvements planned, but I'm not sure about their prioritization.

> CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw)

Hm, could you write a feature proposal for this [1]? It sounds like a great improvement.

> No Custom CSS (yeah our logo isn't 72px x 72px...)

We're extremely hesitant to do this, as we make many changes between releases. This would break custom css with every upgrade, in turn resulting in a worse experience.

I rather hear suggestions about specific parts in the interface that should be made customizable or suggestions about changes to the UI altogether.

Although I'm not a fan of custom css, there is an issue to discuss this and I welcome your input there [2].

[0]: https://about.gitlab.com/2016/01/11/being-a-good-open-source...

[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/new

[2]: https://gitlab.com/gitlab-org/gitlab-ce/issues/15635

Actually as already said even with the stuff mentioned here, it's really really a good project and we are happy. to [0] we've gone the CE route first since we are too small and too fast running that a EE makes sense yet (too good that you can switch between the two without any major drawbacks [http://docs.gitlab.com/ee/downgrade_ee_to_ce/README.html] and [http://docs.gitlab.com/omnibus/update/README.html#from-commu...] thats one of the major selling points, ease of use is really big in gitlab). but sitll every feature mentioned here wasn't in bitbucket so it's not like we've missing something, we've gained something while switching so we are probably whining on a really high level ;)

Oh and thanks god for the easy backup stuff, which even works while running (which other products doesn't....)

Thanks merb!

> - CI is a little limited compared to a full blown Jenkins - We hit a CI bug which still shows up "Running" Pipelines

Do you have more examples of workflows we are not supporting at all or well enough?

> - Artifacts API is limited to everything or nothing

Right you are, you might want to track this issue[1].

> - CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw)

I don't fully comprehend what you mean, could you elaborate?

[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/20603

Not supported Workflows: - JUnit XML or similar output reading to have a nice output what's broken / worked - Checkstyle output / pylint / tools for other languages - What I said about Artifacts - Artifacts are hard to Track I already wrote into [1] which would also be a good way - Actually external Triggers can't be conditional:

https://gitlab.com/gitlab-org/gitlab-ce/issues/19826

So either that or have a way to name triggers which I opened here:

https://gitlab.com/gitlab-org/gitlab-ce/issues/20574

And I guess these are the things my company does / did with jenkins.

There is also another downside but we don't do that anymore: You can't push from CI to master branches, some people do tag and create builds with their CI / CD (which we also did) but now we just push a Tag to the Repo and the CI will be: '- only: tags' and catch that up.

That's all stuff I can think of now which is probably not supported by most "simple" CI / CD Tools. I guess only the big one's have such a thing like TeamCity, Jenkins and Bamboo.

I'm working on a proper Docker setup for GitLab development which I think can be made production-ready pretty easily after the development version works.

It's hard separating the different moving parts (gitlab, gitlab-workhorse, gitlab-shell+ssh, postgres/mysql, redis) but I think I will have a merge request ready soon enough :D

Wow, this sounds great! Do you have anything to share?

Do you leverage GDK? [0]

[0]: https://gitlab.com/gitlab-org/gitlab-development-kit

Not right now. I'm following the install from source guide so it'll be as close as possible to production. I'll change some things the omnibus package does better, then apply the GDK stuff so people could use it for development.

I have some code. I guess I can submit a merge request + issue on gitlab-ce and gitlab-workhorse, but I need to read CONTRIBUTING and PROCESS first :P

Gitlab is pretty awesome, especially because they let you have unlimited private repositories on their website. So far my biggest annoyance is that when you click on a project you don't get a list of files (like you do on github) but just the projects readme, and even then only if you remembered to capitalize it.

In Settings you can set the "Project view" to Files view and it'll give you what you're looking for :)

https://gitlab.com/profile/preferences

How about costs compared to Bitbucket? I appreciate what you guys are doing but I think Github is cashing in on their brand and for a while they had the best UX (they still might! but I no longer care anymore as all the competitors are "good enough" for me) which lets them set a high premium people will pay. However, I think it's unfair to leave out Bitbucket, they have come a long way.

The first example of 8 developers and 20 repos is $10/month

or 100 developers and 300 repos examples is $100/month

What is the cost and/or time involved in maintaining DigitalOcean (or whatever VPS)? Security updates, upgrades, redundancy/availability, backups, or when something goes wrong the time involved in debugging/fixing (github/bitbucket have had their problems, is gitlab 100% available w/o hiccups)?

Very little time, in my experience. unattended-upgrades takes care of most security updates, a gitlab update is just "aptitude update && aptitude install gitlab-ce", and it automatically handles offsite backups.

If availability, security, backups etc. are highly critical for you and you don't want to host yourself, you could also have a look at our GitLab hosting service called GitHost (https://githost.io). It gives you your own private and secure GitLab instance on DigitalOcean which is completely maintained by us.

GitHost for teams of up to 100 is $80/month.

I find Githubs UI pretty poor.

I tried their free tier and it was just extremely slow. A small project where commits usually took 5 seconds now needed >1min for any operation.

Moved it all into the google cloud and it works at the speed of the network. But we don't really need any of the features except the git repository anyway.

Free tier as in self-hosted GitLab CE or GitLab.com?

Self-hosted might be slow if you don't have enough RAM on the system you're running it with, but as long as you have more than 2GB it definitely shouldn't take more than 1 minute for a basic operation.

As for GitLab.com, that can be slow (we're working on improving it, much better now than it was last year, but still progress to be made!), but it should never take more than a minute, otherwise it'd just timeout. When did you try it out?

If GitLab's issues allow you to mark as unread or flag it in any way to come back to it, then I'm sold.

I can't believe this still isn't a Github feature. I don't know how many times I've lost track of issues or forgotten because I can't flag them.

You'll be very happy to hear about Todos[1] then! You can add a todo or mark it as done from the sidebar on any issue or merge request. It'll stay in your Todo list until you mark it as done or comment on the issue/MR.

We'll be waiting for you at https://gitlab.com/users/sign_in :P

[1]: http://docs.gitlab.com/ce/workflow/todos.html

FWIW, I recently transferred my side project from bitbucket to gitlab and I'm really happy with it. The issue tracker is significantly better, and the built in CI seems great but I haven't started using it yet since I already have codeship going.

I did the same last month and then transferred back to bitbucket.

The response time on gitlab.com was painfully slow. That extra 2-3 seconds waits for each commit was enough to drive me back. I still use github for professional projects and bitbucket for personal ones.

I can imagine that GitLab.com was too slow. We just (two days ago) added another storage, where new repositories are created. That should be faster.

I hope you're willing to give GitLab another try when we've improved the performance of GitLab.com or by hosting it yourself.

Follow our work on GitLab.com performance here: https://gitlab.com/gitlab-com/infrastructure/issues/59

I had the same experience. The other thing I would add is that the social side of Gitlab is not as refined as GitHub's. There's no "timeline," for example.

I pay for GitHub and enjoy it.

On the other hand, gitlab's "network" view of commit branches is excellent and I've never been able to find anything remotely similar on Github. Essential to manage development in multiple concurrent branches.

Isn't that just gitk[1] or tig[2] (my favorite)?

[1] comes with git, screenshot: http://static.lwn.net/images/ns/kernel/gitk.png

[2] http://jonas.nitro.dk/tig/

It's similar, but gitlab's graph has a much more readable and sensible 2d layout. The way tig and gitk line up/layout the branches is often very confusing. Gitlab makes it much clearer where the branch lines go, while tig/gitk seem to left-align everything as much as possible, making the lines twist and turn and difficult to trace.

By "timeline" do you mean the GitHub activity feed on the home page when you're logged in?

We have an Activity feed which you can set as your homepage if you'd like, though maybe it's missing features you'd like?

I've run Gitlab for about a year now and I think it's great.

However it is sluggish on a 1GB box and I think you need at least 2GB. Since Linode doubled the RAM on their $10 boxes then you can get it for the same price.

My gitlab-ce instance runs on a vm on an internal hypervisor machine. I just upped the RAM provisioning from 2gb to 4gb, and now it's plenty fast.

One of the benefits of working for a software company that started in the pre-cloud era is a surplus of server boxes, now retrieved from colo racks. :-)

If your concern is cost, bitbucket always have free private repositories. If your looking for privacy and protect your sacred code, install gitlab on one of your server or vps. Thats what we do at SAIT

Fair point, but it's important not to fool ourselves in terms of data safety or at least specify what we mean when we say "it's private on your vps".

If your code is private and not meant to fall into external hands, then putting it on a VPS won't protect it. The only way is to put it on a machine that's only used from workstations that access it in a local-only fashion, inside containers/vms that have no way to contact the outside world. This means the build process may not access the internet and has to rely on a cache of external libs if needed and allowed. This also implies that network config won't allow access as forbidden via VLANs or similar measures.

If someone wants to steal your code, grabbing it from your vps won't be harder than doing the same on github/gitlab because the procedures to get access will be very similar.

I suspect by private code you mean code which shouldn't be publicly clone'able but isn't behind locked doors otherwise.

I recently moved my personal project from GitHub to GitLab and the whole process took me less than a minute, with a simple git remote set-url on the client side. The future is amazing.

That's great to hear. Would love to hear your feedback.

Sure! The only reason I wasn't using GitLab before is that I had a writer working remotely on my game and I didn't know how to explain to her how to use it. So I had moved everything to GitHub and told her to use their desktop app, which makes the clone/commit/push/pull flow amazingly simple.

Not wanting to diminish what GitLab is doing, but what you mention is an inherent characteristic of git itself that applies the same way to GitHub, Bitbucket and a self hosted git bare repository. Any git host should expose a git interface for it to work as a git repository.

Yes, but they simplified it a lot. I just connected to github, chose the repository and clicked import. Maybe all of those services have it that way, but I'm just glad that GitLab had it.

That is a different case than configuring a different remote on config and pushing to another host which is what I interpreted reading your comment, my bad.

Out of curiosity, does the import process include all issues, PR and comments?

almost, yes. issues, wiki, PRs and comments are imported. Afaik cross repo PRs are not supported yet. But they're working on that. :)

For sure, progress on that is in https://gitlab.com/gitlab-org/gitlab-ce/issues/15528

(BTW labels are also imported)

Have you tried using GitHub Importer for any projects?

https://github.com/new/import

Let me know how it works for you; happy to provide feedback to make it easier for your purposes!

Gitlab users: How many hours per year do you spend on doing maintenance for your setup? (servers, updating, backups, troubleshooting, etc.)

I login to my server once a week and run a yum update. Backups are scheduled, so I don't have to concern myself with that.

No troubleshooting. But we're a small (<10 developers across 4 repos with access granted to ~ 30 people to GitLab for ticketing) team. Even my non-technical people are able to use GitLab for ticketing without bugging me, so that's fantastic.

Love it.

Spent 30m installing it and configuring SSL. Nowadays I spend a couple of minutes monthly doing "aptitude update && aptitude install gitlab-ce" (after 5-15m reading about the new release, to see if it's worth it / problem free). We never had an issue with the auto-upgrade.

It comes with support for automatic offsite backups (we use S3), so besides occasionally restoring to make sure they're working, that takes no time at all.

0 hours, we pay for the hosted option via https://githost.io/

I'm using paid GitLab hosting via the GitLab-owned GitHost.io, so zero: everytime an update comes out I get two e-mails and that's it.

The pricing is extremely competitive. We are a small shop so the smallest package ($35, recommended for up to 30 active users) is good enough. We started with a self-hosted GitLab via docker and switched to GitHost as soon as it was bought by GitLab.

If you don't want to maintain GitLab, either CE or EE, but would like to use it, you might want to take a look at GitHost.io

The instance I maintain takes me about 15 minutes a month. Security updates are done automatically so all I've got left to do it 'apt-get install gitlab-ce' once or twice a month and thats it!

Originally rigging gitlab-ce took a couple of hours, including standing up a VM, and setting up an S3 bucket for fire storage.

Checking backups once a week, 3 min.

Updates twice a month (using apt-get upgrade) 10 min counting integrity checks.

Nuisance factor: updating gitlab-ce drops a tiny little backup file in the backups folder.

If you want to skip the mini backup before upgrades, run:

`sudo touch /etc/gitlab/skip-auto-migrations`

Docs on it here: http://docs.gitlab.com/omnibus/update/README.html

Like 5 min install it, ~30 min configure it, then about every two weeks spend 5~10 min check any new release and release notes, then just "docker-compose pull && docker-compose up -d" to upgrade.

GitLab is great and it's lovely to see a diverse selection of tools, but I'm not too convinced of the cost benefits – for a team with 100 developers, the annual cost of ~$11,000 is a pretty small amount compared to the maybe $25m salaries you'll be paying!

Avg salary of $250k per dev? Are you hiring?

Well where I live, the final salary you get in your pocket is about 60% of what the employer has to pay (the rest are taxes and "social charges" which include medical insurance and retirement funds). If it's the same where OP lives, then he was probably thinking about 125k salarys + taxes, charges, etc.

Also, he must be considering other expenses that come with having employees (though he did say "25m in salaries").

Still, if you bring the salaries to 100k a year, it still compares favorably to GitLab: $11k vs 10M.

You of course realize that "salary seen by the employee" is not at all the same as "costs payed by the employer". (For example, social security and health insurance).

I would guess fully-loaded cost is 2x salary, so perhaps I should have said "amount you'll be paying for staff" :)

Could you take a look at price for GitHub for same big team please?

Sorry, that was my point – Github is ~ $11k for a team of 100 developers. The difference between '$11k' and 'free' is basically irrelevant when you are paying > $25m for your engineering team in the first place!

Somebody has to establish it's one of the most reasonable choices, and convince the checkbook holder it'll save the team two week's work.

Dumb question:

For self hosting, what's wrong with a shared file server and nice GUI such as TortoiseHG?

There seem to be a bunch of Git GUIs as well:

https://git-scm.com/download/gui/linux

What is the benefit of moving to Gitlab from Bitbucket (or Github) for private repos? Same feature set, Gitlab cost more per user and on top of all you have to run your own server? Am I missing something here?

I'll leave the marketing talk to less biased people here, but do note that:

- you can use GitLab.com for free: unlimited public and private repositories, unlimited collaborators, free hosting of your Docker images, free hosting of your static site with any static site generator and free CI / CD

- GitLab CE is fully open source (MIT Expat). You can easily install it anywhere you want.

"you can use GitLab.com for free"

It seems like that is the main selling point. However, I think that most of us don't want the extra weight of managing yet another tool. Thus why many of us use GitHub to begin with and not something else...

What do you mean with managing another tool? GitLab.com is our own instance, that we manage.

My fault, I didn't see that there was a free hosted version. I thought it was either free self-hosted or paid hosted.

Just to clarify GitLab.com is their hosted version, not the self-hosted option (Which is GitLab CE)

Yup, my mistake.

Isn't GitLab.com managed? It's a bit slow when using the web interface, but it's free.

Nothing is free in life. You should define free because it's border line a buzz word now.

You can use GitLab.com with no charge. It's free in the same sense as GitHub is free, except it also runs on open source software (well, GitLab EE, which is a superset of CE and has a proprietary license but is still developed and supported in the open unlike GitHub).

AFAICT the "cost" is that you're effectively load-testing GitLab EE and help guiding the development of a commercial product. Plus you're giving GitLab free marketing. But to the extent that anything in life can be considered "free" (as in "gratis"), GitLab.com can be used for free.

This is correct.

We're thinking about charging for specific GitLab Runners in the future (think Mac Runners) or additional storage (we have a soft cap of 10GB per repo).

My big concern when I see a company that gives away too much for free is that they are probably unprofitable and will at some point:

a) Start charging for things that I'm used to having for free

and/or

b) Go bankrupt/get bought out by a company and disappear

Do you really sell enough enterprise licenses to give all the rest of this stuff away? From a look at your site, that's the only source of profit for your company that I can find.

Our main source of income is subscriptions that grant access to Enterprise Edition and support. That has been going very well.

We're not planning to charge for what we give away for free now. Never.

We're thinking about charging for specific Runners for our CI (such as Mac runners) and possibly for extra storage.

You mentioned Mac runners, and if this includes iOS you'll make a killing. Figure out how to interact with a fast Android emulator and you'll be able to pull in a decent chunk of agencies that don't want to buy in house build machines.

We are a company of 10 on GitLab CE (We selfhost via the Cloudron). Costs us ~60 a month, so it's already cheap for us. We also have a bunch of other apps on it which saves us more money.

> GitLab really started accelerating in 2015 as this commit graph shows

They're using a Github commit graph to show how good Gitlab is? GitLab's graphs aren't as nice? :)

Does Github has a on premise offer like Bitbucket or Gitlab ?

Github Enterprise.

Indeed we do. GitHub Enterprise 2.7 was just released yesterday:

https://enterprise.github.com/home

I would like to see that there is just one gitlab version, and that the enterprise features are simply available in the community edition too. I will not pay just for a feature like repo mirroring, but it's i think a feature many people will use and or utilise when moving, migrating to a gitlab setup.

But it is the one and only feature i am missing so not worth upgrading to EE for me.

As soon as an alternative (open source, self hosted, free) comes around that does have this built-in, i will be tempted to try it. (and of course on success i will move away from gitlab).

But for now, gitlab (CE) works best for me, self hosted.

We do our best to make CE and EE excellent, where the features that land in EE are mostly interesting for larger teams. For every feature that we don't bring to CE, this is always a hard decision.

We wrote about this here: https://about.gitlab.com/2016/01/11/being-a-good-open-source...

I'd love to see an a la carte licensing option, where an organization could start with stock CE and license just the features they need. I realize that'd be a bear to implement, though.

Hoi Job :) mogguh

I understand, and money has to be made too. It's a nasty trade off. Though as i wrote to the other reply, its the service that is worth the money not necessarily the feature(s).

IMHO, there is always a certain percentage of users that want to pay. The more users in total, the larger the amount of paying customers.

And the repo mirroring would be a great feature to let me move a lot of github project users to gitlab without losing any potential updates from an upstream source.

It would also allow for nice backup purposes, though you could do that now of course already with the hosted enterprise solution. But if the feature was in CE, many would be used, familiarised, to the feature, and perhaps see the added value of a backup node ($$) at gitlab.

If you think about what you're asking: youre asking for folks who build infrastructure you rely on to have no viable way of creating a self sustaining business model. Aka no virtuous circle. No development. This perspective is a classic tragedy of the commons situation and makes perfect sense for you to have as an individual. But it's sad.

There will always be users like me who know how to self host stuff and don't want 3rd parties having access to their repos. But there will always be plenty of people who like to outsource this, have it hosted by 3rd party etc etc. It's the service that is worth the money, not the features.

Features have a limited value, they are valuable until an alternative provides it for free (which is the common thing these days). And that will happen here too, just take times. Same as gitlab nibbled at github, something else will come around to take share from gitlab.

Simplifying the development to just one tree/version, saves a lot of maintenance, development discussions, allows feedbacks of all features by self hosting users as if they were enterprise hosted clients. This also has a value.

I wasn't refering to hosted vs not hosted. I was referring to the virtuous cycle of supporting people by giving them a viable business option who make software (whether FoSS and deployed on local infrastructure or hosted).

Do you believe Linus Torvalds deserves to have a salary? Are you happy he does? I sure am. Do you think that money grows on trees? It comes from people realizing that it's important to contribute to sustain the pieces they rely on. The majority are always free-loaders: I just think it's important to emphasize that if everyone were, the cycle of innovation would slow significantly.

Happy with gitolite. It's just fine, no need for a web interface.

Their UI is too slow (as many other Ruby web apps).

If you're talking about GitLab.com, this is due to other issue https://gitlab.com/gitlab-com/infrastructure/issues/59

If you're talking about a self hosted instance, we think it is OK right now and frontend code will get better now that we adopted https://vuejs.org/

Small nit pick, why DO and not Linode? Faster CPU, more RAM and Bandwidth, cheaper as well.

Not sure why the downvote, the article keeps bagging about saving cost, when Linode would have been a much better fit and cheaper.

This isn't another ads or trolls. It is similar to AWS topic and recommending GCP, or Microsft Azure, all three are classed as similar with different tradeoff. So is Linode and DO. I do not think there are any other VPS provider then are in their class mindset wise.

Interesting. For projects that don't need a "community" we've been using Amazon CodeCommit.

We don't like to use Github anymore because of the politics there. Example: We had a project involving software filters that included this sentence in the description:

> Phase is related to time, but a pure time delay does not involve any phase shift. A pure time delay or "group delay" is constant with frequency. Phase shift varies with frequency and can advance or retard as the frequency changes.

We got a note from a woman who works at github who was apparently scanning open source projects for "offensive" words. Our project was flagged for the use of the word "retard".

We removed our project and never used github again.

We removed our project and never used github again.

That seems like a totally disproportionate approach versus responding with a polite 'this is a legitimate use of the word, thanks' message.

I would agree with you, if it weren't for all the other articles that have come out about politics and github.

People on the internet will make lots of noise about everything; paying undue attention to it is a bit silly, IMO.

we're not talking about anonymous web forums, we're talking about a git repository. It isn't "silly" to be bothered by random github employees scanning and flagging keywords

Anything and everything posted online can be handwaved with this argument.

Maybe she actually could've read the text and figured it out herself before sending out the note?

Just firing off a warning based on a simple text match seems high-handed and/or incompetent enough to consider leaving.

Just to be clear, you're saying: "If large company x hires a single incompetent person, that is a good reason to never deal with said company again." I think that's the parents interpretation of OP and hence the "seems like a disproportionate response." (I agree it was absurd to flag the content).

Absurd being the key word. This isn't a simple misunderstanding we're talking about, it's a company employee using company time and resources (i.e. sanctioned by the larger company) for something that can charitably be described as misguided.

It raises questions about the internal company culture, their commitment to pragmatism (doubly important for a source code hosting site), and their priorities. Any developer could have told this person that a string match does not equal a linguistic match.

Small signals matter; they're usually all you get out of large orgs.

When there are numerous alternatives to GitHub why would I continue to use them? Clearly they were not putting the time and effort in to both train their employee and review the content (simply reading the sentence would give context), why bother dealing with them?

Also why as a code hosting service would they be getting involved with the politics of the content of projects they host?

That's oversimplification. Even if it is just her own personal incompetence, if GitHub just hired her and let her loose as some kind of independent repo ombudsman to scold users, then yeah, that's a terrible management decision that warrants reconsidering your relationship with them.

We don't even know the whole story. The "woman" who sent the note is most likely just be an automated script.

Then apply the above-mentioned logic to the person/company that endorsed/approved said automated script.

The point is the same though. Resting a project's livelihood on a company that employed obviously incompetent process/humans/scripts is a risky move, and removing that livelihood from that company makes total sense.

It doesn't sound incompetent to me, there will always be false positives on that scale. Did they remove the OP's repo, or simply send them a message? If a legitimate email gets caught in your spam filter, do you switch email providers? Github and their process/humans/scripts don't sound like the incompetent ones in this scenario. I would be more concerned that my livelihood depended on such an over reactionary company.

"Hey boss,I tried cloning the Github repo of project X, but it says it can't be found, and I noticed our org page on Github is gone."

"Oh yeah, they sent us a message about the use of the word 'retard' in when referring to phase shifting."

"Oh, so they deleted our organization?"

"No."

"Oh? Well why can't I view it, weren't the projects public? What did you say to them?"

"I didn't say anything, I moved us to a different host."

You're injecting a lot of assumptions into your narrative.

My point is simply: if Github is flagging content based on perceived personal morals (not ever being allowed to use the word "retard," even in legitimate contexts), some choose not to associate their work with them.

And their bots hide "your profile from the public", when you are hit:

https://pbs.twimg.com/media/CpGcXmQXEAAyJU4.jpg:large

Even then, they still wrote the automation. It would be a prudent move to involve human review before emailing someone and accusing them of making a bigoted slur.

People who represent themselves as employees of a company represent the company. If the company permits incompetent employees to behave like this on their work profiles, that's not an unreasonable deal-breaker.

I don't really want my code repo judging me for my word choice.

A company shouldn't even waste time for things like that could.

I'm definitely not interested in company I'm paying for investing resources retarded things.

- a happy gitlab user.

Presumably it was an automated message.

Someone had to design that automation. And it sounds like the message was at least made to look like it came from a person.

Go read up on Github user: CoralineAda [1][2] Then consider that GitHub hired her. I would not be surprised if the this automated script and her employment were directly related.

[1] https://github.com/opal/opal/issues/954 [2] https://github.com/CoralineAda?tab=activity

> Then consider that GitHub hired her.

I'm not terribly surprised. GitHub is, after all, a company which changed its logo to celebrate a highly political U.S. Supreme Court decision and which has had issues with left-wing racism (http://www.businessinsider.com/github-the-full-inside-story-...).

I really don't want this to be a witch hunt (not seeing that here, just wary of pointing out individuals)—this is exactly the type of thing a business should take responsibility for as a whole. This was a process failure, IMHO.

Exactly. The point of my comment was just that automation is no excuse for this kind of thing.

For me it's still about the organization, and singling out individuals is about as productive as yelling at customer support on the phone.

I think you guys missed my point. In pointing out one individual, I was pointing to the organization as a whole. Github supports this kind over-sensitive social-activism. Example A: dragnet language-police script. Example B: hiring controversial, social-activists.

For better or worse, the appearance of coming from a real person seems to be the trend in marketing automation. I think many people, especially outside of tech, believe they are interacting with a real person most or all of the time, when in reality, they only are during exceptions to common requests. But people like interacting with real people more than they like seeing "automated message blah blah".

Related: The company is slipping my mind right now, but one startup changed their email name in automated messages from male to female and saw improved metrics as a result.

https://en.wikipedia.org/wiki/Marketing_automation

I actually assumed that this message was automated – "We found on objectionable word in your project, please don't use it."

It just seems that this problems is remarkably easily solved with a simple "We are using a technical term correctly, maybe you should consider adjusting your automated emails."

I do get the impression that people generally seem to be all to eager to take offence, and it strikes me as a bit ironic to flounce off in a huff as a result of a badly-judged automated process!

> I actually assumed that this message was automated – "We found on objectionable word in your project, please don't use it."

How is this any better?

I find it worse. Github provides a great service and certainly has provided an incalculable value to os, but at a project level, it doesnt provide nearly enough value to dictate word choice, etiquette or style. Yes, the service is free, but github needs high caliber os projects more than they need it. It dosnt even matter who has an edge, automating spam at a user who says a naughty word is silly.

Idk, i dont understand why they would even care. Unless it reached a very intolerable bar, i dont think this is necessary

We moved from GitHub to GitLab CE at our company and co-workers started using GitLab.com for their personal projects, moved away from github.

Perhaps to a comment from a random user, this would be disproportionate. But when it is a GitHub employee sending these messages, someone needs to communicate the issue to them in metrics they will understand, like projects leaving.

You shouldn't have to explain proper English or put up with someone who doesn't understand proper English subjecting you to a political litmus test.

It's a political act to publicly declare something along the lines of, "I quit because of their politics."

Fortunately, people like me see such declarations — "Hmm, I'd better now reactivate my paid GitHub subscription, and stop pushing people to competitors. Their attitude is improving!"

I stopped using Github when they hired blatant racists as part of their 'social outreach' team. The infestation of politically-correct politics drives talent that can't be bothered with such cruft away.

I was there to code. Not worry about if I hurt some oversensitive person's feelings for referring to master/slave copies.

I wrote this elsewhere so I won't repeat it here (https://news.ycombinator.com/item?id=12232883)

We're all on Github to write code, but I'd argue you are dangerously close to throwing the baby out with the bathwater there. It seems perfectly reasonable for someone to say "hey, this term you use might be offensive/makes me uncomfortable, please consider changing it." It's also perfectly legitimate for you to say "I don't want to do that".

I just kind of wish that everyone would be a little less sensitive about the prospect of other people being offended by things that they are not. Political correctness, in the sense of "try not to say things that are offensive" sense, is probably not the worst idea in the world!

>It's also perfectly legitimate for you to say "I don't want to do that".

At which point you get harassed by a mob, spammed with issues that clutter up your project, and get emailed death threats.

Github is allowed, of course, to choose which projects they decide to host. Demanding the removal of the word "retards" [0] or a project would be shut down drove at least one developer away.

So no - that isn't "perfectly legitimate" for that community. "I don't want to do that" is not good enough.

[0] https://github.com/nixxquality/WebMConverter/commit/9fde8f33...

It's "the worst idea in the world" because it perpetuates the idea that certain words or thoughts are taboo.

This doesn't mean people stop having them.

This just means that they are labelled/judged if they have them.

Guess what happens then? People keep it to themselves. And then they vote for Trump. Why? Because, he is a ridiculous loudmouth who is very out of touch with most of reality. But, he doesn't feel the need to be censored. And to people who haven't spoken out due to fear of reprisal, this is an admiral characteristic. He gives them validation.

So yeah, political correctness is retarded.

I think it's reasonable if only so you can avoid the overhead of needing to deal woth censors. There's also a lot of overlap between open source and free speech, so I can understand a natural distaste for censorship in general.

To olay devil's advocate, what's wrong with offending people who read your source code? You can't harass people through source code in a meaningful way because you can't force them to look at the code through natural interaction with GitHub itself, if they see a project that is insulting, they can just ignore it.

It's not like a social media site where you can ensure your victims' feeds will be polluted with your insults.

How about it's offensive that a company that bills itself as an open source hosting company even employees (incompetent) morality police? Really, scanning projects for naughty words?

Assuming Github's ToS applied here, it's unlikely that the project owners would have succeeded in keeping the content as is on github by arguing for it. This is regardless of the legitimacy of the content. Being on Github isn't critical for every project, and we need more projects that have their primary location on Bitbucket, Gitlab, etc. instead, in order to break the Github monopoly by making it normal that it's fine to use a different site for a project.

It cannot be healthy to have all our eggs in one basket (Github), regardless of how featureful and nice Github is, especially so given the availability of viable options. To that end, we should not complain when a project, say, evil-mode is on bitbucket, and similarly not ask a project to open shop on github.

I mean, if we don't work towards a fully distributed project model ala fossil-scm (via things like git-appraise), we should at least use alternatives when we can, and not strengthen Github's monopoly.

Github does have the lead in terms of exposure and discoverability. To take advantage of that, I've left placeholders in all my projects that are elsewhere now: https://github.com/caseysoftware/marvel-php

If you find it on Github, you can find out how to get started but everything else is on Gitlab.

Looks like a very big sign that more warnings will come later, and you'll have to spend time fighting such things now, and start worrying about your data be cut from the site without previous notice.

Going away is the correct response, fighting the decision is never useful. One might wait a bit to see if it's a fluke, but that will certainly depend on the GP's evaluation of the company.

Given no other information I would agree. But given other information both about Github and about the kind of processes that seek you out to tell you that you are being offensive, I understand. Maybe this was a one time thing, maybe it will be another donglegate. If it is easy enough to move, why wait and find out?

It seems like the action from the github employee was disproportionate. That sounds like a very risky environment to host your product on. The response seems to match the proportion of the action.

Maybe if they had some allegiance to or belief in Github fixing the issue, talking to employee, retraining them, it might be worth. But when there is another project that is just as easy to use, it often just easier to drop it and switch.

Also that interaction with Github, can be interpreted as a pointer to larger systemic issue (for better or for worse) which the customer doesn't believe will be solved with a simple email.

It's quite disappointing to see people defending a company that hires bigoted political activists to crawl users' projects in order to harass users for perceived political transgressions.

And what level of access do these on-staff political activists have to private user information? What measures, if any, does GitHub have in place to prevent one of their political activist employees from using privileged information to go after perceived political enemies or even just retaliate against users who protest being harassed?

It's quite disappointing to see Hacker News users use hyperbolic language and throw out nonsensical arguments.

What is "bigoted" about trying to avoid the user of the word "retard"? I'm not saying that what Github is doing is wise or sensible, but I'm struggling to see how it is bigoted.

> What measures, if any, does GitHub have in place to prevent one of their political activist employees from using privileged information to go after perceived political enemies or even just retaliate against users who protest being harassed?

I would imagine the same as any other company. There's nothing that would indicate otherwise, aside from your own biases against Github.

... and risk of it escalating into a (potentially career-ending) Internet knife-fight.

You mean like when the parent poster did this: https://news.ycombinator.com/item?id=12233452 ??

She indicated that it doesn't matter how the word is used, some will see it as aggressive.

No, it isn't.

A customer can choose to take their business elsewhere for whatever reason, at any time. I mean you can speculate as to whether it was disproportionate or not, but the only determinant here whose opinion matters is the paying customer.

Typically US, blocking the use of such words. Everybody says 'fuck' in the US, constantly, but whey you use it on TV or post it online, all hell breaks loose. It's just a word folks, get over it. What is the worst that could happen when you see 'fuck' or 'retard' somewhere?

I'm also curious on how many downvotes I will get for this, because the polite way is to use f*ck or something, right?

This was also one important reason why I am switching. The price, the enjoyment of hacking are primary reasons, but the politics pathway bothers me as well.

I know HN frowns upon "me too!" comments.

But ..

Me too!

I now use gitlab for my company and haven't noticed a difference.

I want my git host to worry about hosting git.

What did the email say?

Wow, that is absurd. Did you ever follow up with the employee who sent you a note? What did flagging entail? I.e., were you not able to use the repo?

Yes. She indicated that it doesn't matter how the word is used, some will see it as aggressive.

As she appeared to be a non-technical person mysteriously employed by GitHub as some consolation to some organization (IIRC it was called the "Ada Initiative") I realized that github is no longer a technology company. It's a Social Justice company. Good luck to them--I don't even disagree with the basic premise--but I like my git repo companies to be worried about git.

Some of the commenters here assumed that the message was automated, you're making it abundantly clear thats was not the case. In fact she defended her position. Did you try to escalate it? This is absurd.

I'm tempted to have a play with this, and see how many legitmate, non-offensive uses of "retard" I can get into my repos.

EG The french for "I'm late" is "Je suis en retard".

Why are you specifying it was a woman?

Moreover, why would he even know in the first place?

Maybe because she had a female name?

Perhaps she signed-off her email/post/comment with a female name? You know, it is perfectly reasonable to assume gender when the name is obvious. E.g. the odds of a person called "Samantha" being male are miniscule compared to it being a female. Because in both cases, "it" is a person we are talking about.

We can't just erase gender. People think in gender, and they consequently speak it. I don't think twice about mentioning "some guy" commented on my post, for example. Just the other day I decided to be even and refer to a hypothetical person by using "s/he", and even got called out on it.

If either of you bothered to read the thread before moving forward with your agendas you would have the answers to the questions you're asking[1].

[1] https://news.ycombinator.com/item?id=12232822

[I'm not OP] Does one have to always make sure not to mention gender in English? I'm from Poland and in Polish you mention it all the time unless you specifically go out of your way not to do so. Before I've seen people criticized for translating "programistka" as "female programmer" and there was that proposal for some NLP library the other day, to drop any functionality detecting gender... And doing that to Polish (or any Slavic) NLP library would make the software useless: emperor/empress,prince/princess,sorcerer/sorceress - it may sound like fantasy to many but this is the reality for language with grammatical gender. I'm not saying there are no biases against women in Eastern Europe, but no one here would find mentioning gender offensive or inappropriate, in fact the opposite is true... I also don't remember such rule being mentioned in my English course.

AWildDHHAppears' post is idiomatic English.

It's not usual to avoid any mention of gender in English; some people avoid it for political reasons. But when you're translating a gender-marked word into an English equivalent which is not marked for gender, it's not idiomatic to add another word to indicate gender unless it's relevant to the topic at hand.

English lost most of its grammatical gender centuries ago. Since the 1960s and 1970s the parts that remain have become politically fraught in some circles, but usage varies by community. Unless you're deliberately wading into that fight, I'd stick to the way you were taught.

I see, recently I'm seeing people being called out on thoughtlessly mentioning the gender. The 'female programmer' was a lazy translation, agree, but I would've also used 'woman' to describe person who wrote the that e-mail if I know that for a fact that woman was the author and question by kmonsen really got me thinking if that would have wronged someone...

On a side not, I do miss that added context in English, especially in novels, when it's hard to guess just based on the names of the characters. It makes it easier for me to imagine them and evaluate interactions between them.

I did the same with my business, personal projects, and open source stuff I worked on.

Github is never getting another penny from me.

I'm offended by her stupidity.. Can I flag her?

Original post: https://news.ycombinator.com/item?id=12224723

Earlier this week I had a family member get spooked by a web site with a fake blue screen tech support scam, the one where they tell you your computer has dire issues and you must pay them $300 to fix it. The page was taken down as of yesterday, but what is Gitlab doing to address this type of abuse in general?

You seem to have left out some context. What does this have to do with Gitlab?

Hosted by Gitlab.

If someone is abusing GitLab please use the 'i' on the user profile to report them.

They can argue rationally all they like; GitHub is the Oracle of VC hosting ... nobody will get fired for choosing GitHub.

So far every early stage startup I've seen was using GitLab unless they only have open source / public projects and can use GitHub for free or need GitHub because of the community (it's still easier to get traction on GH as an open source project because so many developers already have a GH account).

GitLab has seen steady growth for years and has recently been gaining an increasing level of attention (in part because of the pricing changes and dodgy politics at GitHub). It's here to stay.

I hope GitLab.com will become more performant and stable. I would love to see GitHub for open source be replaced with a company actually built around open source rather than proprietary tech and catchy marketing.

Reply on news.ycombinator.com