Hacker News new | past | comments | ask | show | jobs | submit login
GitLab 8.5 released (about.gitlab.com)
603 points by doubleg on Feb 22, 2016 | hide | past | favorite | 241 comments



Looking at this thread here, Gitlab seems to be much more open about their development than Github, and has a real sense of community, yet Github (still) remains the popular option, despite their more community-hostile traditional board-meeting decision process.

Is there a gradual shift in the FOSS community towards Gitlab (which in all honesty would make more sense), or am I just seeing the enthusiast in this thread?


Github's shortcomings only really came to the fore in the last couple of months, due to a combination of factors. GitLab is working hard to exploit the current window of opportunity to make waves. I'm slightly surprised BitBucket is not doing the same, but their Atlassian masters seem more interested in pushing irrelevant features at the moment (like SSO across products I don't care about).

It's too early to talk about a shift away from GH, but increased variety in the ecosystem can only be a good thing, compared to the dangers of a GH monoculture... especially considering git migrations are literally just one push to a new origin.


Atlassian is going after the enterprise market. They don't care about free software developers.


That's a poor strategy. All developers start out as free software developers, then gain employment. I persuaded my work to purchase Gitlab EE licenses, due to ease of use and it's excellent features & support. I can't imagine I'd say the same of Atlassian products.

Capture awareness / interest early.


You'd be in the minority. Correct me if I'm wrong, but I'd bet you're at a small company where a low-level employee's opinion was taken into account when making the decision of which product to use for 10-50 people.

In medium to large sized companies, Atlassian will usually win out when you have a CTO that manages 100+ developers. Enterprises really like to stick with the "safe bet", where there are expensive licenses and dedicated account managers from the service provider.

Jira in particular is extremely popular with the modern addiction to Agile. Once you're on Jira, you just start to fall onto connecting all the related products like Confluence for wiki and Bitbucket Server (formerly Stash) for git. I'm not saying it's the best thing to just ignore all other offerings, but in my experience CTOs do exactly that and just go straight to Atlassian for everything.

Basically, if your company is using Exchange... expect to be forced onto Atlassian. Welcome to the enterprise.


I've used plenty of other options- we even ran an internal GitLab instance prior to moving to BitBucket at my last company. Atlassian's suite of products are a safe bet because they're generally good products.

I like the GitLab feature set more than BitBucket but when I went started my own company it was generally cheaper for my team of 5-8 to use hosted JIRA, BitBucket, and Confluence then it would be for me to pay AWS/Rackspace/Azure/Digital Ocean to run the F/OSS equivalents in our cloud environment. BitBucket integrates just fine with Jenkins and the new Project organization was much needed.

We may someday move to GitLab or something else, but there isn't anything wrong with choosing Atlassian in any way. It's not like they're an Oracle/SAP type company that just abuses their customers and has awful products.


Great to hear you're using JIRA, Bitbucket and Confluence together. How is the integration between the tools? It's definitely a use case we're hearing more often where teams need more than just storing and working on code.


They're getting better. BitBucket and JIRA work together quite well. With "Smart Commits" in the JIRA hosted version that allow us to move a ticket's status, comment on it, log time, or just show activity towards a ticket via Git commit messages. I use the heck out of it and the team is following quickly behind.

JIRA follows the feature branching workflow pretty well, so if you branch from dev/master with the ticket number as the start of the branch name you can click through to that branch straight from JIRA, which is generally pretty nice.

Confluence isn't nearly as tightly integrated with either. There are some reports, widgets, and stuff you can grab out of JIRA and make some dashboard type reports. Nothing special- we use Confluence to document architecture, deployment procedures, etc. We're definitely not Confluence power users.


If you want to use GitLab on the cheap consider using GitLab.com, it is totally free and has unlimited repo's and collaborators.


It's so funny that this is the way it's become, as Atlassian grew up being the cheaper, simpler alternative to extremely expensive, super opaque, ultra closed source systems like Clear Case. I remember a time when Atlassian actually raised the prices of Jira's top level of support and service because enterprise CTOs were confused by such a low price point.


Ten years ago I made exactly this migration for a SaaS shop's helpdesk & dev team. At the time JIRA was easily the best value & most customisable solution for integrated ticket tracking. I learned Java & Groovy to write extensions for it. It wasn't just CTO/CIO friendly, JIRA really was the great choice at the time in both UX and ease of implementation. Especially if you'd been bogged down hacking RT or GNATS or permanently scarred by anything from Rational.

What I realised is that eventually they're all ad-hoc, informally-specified, bug-ridden, slow implementation of a workflow engine and metadata service. Your choice is mainly of the interface and domain-specific layering violations.

Troll-friendly soundbite: Atlassian is the new Rational.


"You either die a hero, or live long enough to see yourself become the villain"

Let us know anything specific you'd have us improve - love to know what changed over the last 10 years to make you change your mind.


> I learned Java & Groovy to write extensions for it

For the last 3 months, Groovy has been officially known as "Apache Groovy".


At $WORK we use Jira/Confluence, and instead of Bitbucket Server we chose Gitlab because I have experience with it, and it comes with integrated CI.

BTW, this is not some small startup...


Cool to hear that! For reference, since many organizations use Jira GitLab CE and EE have extensive Jira integration http://doc.gitlab.com/ee/project_services/jira.html


Yep, if that didn't exist we would have had to go with Bitbucket Server.


> All developers start out as free software developers, then gain employment.

I don't think that's true. Some people never get involved in free software even as a hobby. Some people get apprenticeships and learn to program from scratch on the job.


Or, strange as it may seem, they learn how to write software from a four-year college degree. And colleges are notoriously bad at teaching so much as source control, let alone what source control options are there, how to use a bug tracker, etc. (Which makes sense, because you don't strictly need source control if you aren't collaborating heavily, and you don't need a bug tracker if you have a single development week-by-week.)


Seriously... My favorite was in a lower level DB class we had to write, basically, a small PHP app connected to MySQL. On the first day of class the instructor stressed this class was about databases, not PHP, and would basically just cover getting a connection going and the rest was up to us. I think having been doing development and getting paid for it via 'internships' at various companies when I was younger really made me a better, but angrier student in my college CS days. On the one hand, I needed zero time to get up to speed on C, C++, Java, and PHP syntax so I could focus on the algorithms and other topics being taught. But I doing so it became very clear that I was going to the real world and most of this stuff wasn't coming with me.


I agree there is something to be said for bottom-up marketing, but asserting that "all developers start out as free software developers" is completely untrue. In fact, I'd guess that people who actually develop free/OSS software are far outnumbered by those who don't.


Yep. I got my work to purchase EE license for Gitlab because it's miles ahead of Bitbucket Server.


Would love to hear what features in your opinion but Gitlab miles ahead of Bitbucket Server.


We tested Bitbucket Server when it was still called Stash, and compared it to Gitlab at the time.

- Merge requests/code review in Gitlab is much better, whereas with Atlassian they recommend purchasing another product

- Integrated Wiki, whereas Atlassian they recommended Confluence

- The UI is absolutely terrible, even now the Bitbucket front-page where it dumps you when logged in is a disorganised mess and I can never find what I am looking for

- Speed, Gitlab running on my own server is MUCH faster, compared to Stash

- There was no way to easily add code snippets to be shared with the rest of the team, ala Snippets.

- Integration with the rest of the Atlassian toolset was so-so, and left a lot to be desired honestly.

- Statistics and information about the code and who is contributing and everything along those lines, makes for pretty graphs that make higher ups happy.

- Bitbucket doesn't currently have a view within the web interface for how many commits have been made to a project. People like numbers, and watching them grow!

- I have to reiterate, the UI is absolutely terrible in Bitbucket/Stash.

And the real killer is that I can get Gitlab CE and never pay you guys a dime, I've in the past helped out in the Github issues with debugging, and I can be part of the community. The only feature from EE that I need is the ability to use LDAP groups to define what users can and can't access various repositories, and the company I work for can afford to help pay for Gitlab's future to stick around!


I'm guessing Atlassian frequently goes after those sort of enterprises were the decisions are made by management with little input from the actual end-users of the product.


> I'm slightly surprised BitBucket is not doing the same, but their Atlassian masters seem more interested in pushing irrelevant features at the moment

Yeah, I fear Bitbucket will always be shackled to the rest of the Atlassian product line, and never really allowed to innovate much.


Hey, Kelvin from Atlassian here. We are pretty flat out ourselves improving both Bitbucket Cloud and Server. I can see how SSO isn't terribly important if Bitbucket is the only one of our products you use, but it's critical for our customers who co-own Bitbucket and JIRA (or Confluence, or HipChat, etc.). It was a fairly massive undertaking: retrofitting auth across our portfolio of products took some serious engineering effort. But we've still managed to squeeze a few fairly large releases out recently shipping features such as smart mirroring, Git LFS, and clustering - and have some other great stuff in the pipeline.


Hi Kelvin,

Any chance BitBucket has a public roadmap? I'm a user because of your free private repos, I hope to grow into a paid user this year. Thanks for all that you do!


Great to hear! Not quite, but we try to keep relevant feature requests on jira.atlassian.com (for Server) and https://bitbucket.org/site/master/issues (for Cloud) as up to date with progress as we can.


Honestly, I don't know why you didn't have SSO years and years ago. You encourage crosslinking between products that have distinct session lifetimes, I feel like I spend all day typing in my password again.

(Also, can you take the fucking 'remember me on this machine' button away? It's a cruel, cruel tease. It has not worked a single time on 4 different installations I've had accounts on over the years)


Did LFS support ship just for self-hosted? I was searching for a home for a few private repos days ago and #11204 showed LFS as still unsupported for hosted BitBucket.

https://bitbucket.org/site/master/issues/11204/support-git-l...


Yup, self-hosted for now but we're working to bring support for hosted soon.


> especially considering git migrations are literally just one push to a new origin.

A pain point here is that GH issues cannot be migrated easily as a git migration (but GH does have a REST api).


But gitlab has a Github migrator which supports pretty much a repos complete history (PRs, issues, wikis, etc).


Yup, I am aware of that thanks to my obsessive reading of HN :-) But I was just pointing out that it's not easy as switching a git origin in case you want to move to something else other than GitLab.


GitLab has a ton of strengths, but still has large weaknesses in the area: gitlab.com implementation and design.

gitlab.com is the public 'demo' version which people compare to github. It's missing a few key items that would make it appealing to open source developers (and that I'd like to see them prioritize.) E.g.:

* Site search. It's been broken for months or possibly years. (Response time > 45 secs., Relevancy is miscalculated: "gitlab" itself does not appear in the search results.)

* Repo / project discovery and social features are extremely primitive.


I agree we can do a lot better in project discovery on GitLab.com. I do want to mention that https://gitlab.com/explore?utf8=%E2%9C%93&filter_projects=gi... gives results in a few seconds and GitLab itself is the first hit.


Want any help?

I don't have any interesting answers for your hiring filters.

The culture you've built is very rare. I realized that if I felt that way, then I should try to help it become the norm.


We always want help, you can contribute directly or apply to work via http://doc.gitlab.com/ee/project_services/jira.html

We take all applications seriously but if you feel you got rejected for a bad reason feel free to contact me directly.


I think your link may be an errant copy paste :)

I guess you meant to paste: https://about.gitlab.com/jobs/


Yeah, that was the page that convinced me I should try to join. But,

"A note on the technical interview: As part of our interviewing process, you may be asked to pick an issue from the GitLab CE issue tracker, and code ‘live’ with the interviewer there to talk with and collaborate with. We do this because we believe that it is the best way for you to see what the work is really like, and for our interviewer to see how you think, code, and collaborate." Actually, it's the opposite of how to find out how I think and code.

Do you have a profile on GitLab.com, GitHub or Bitbucket?

No.

What (open source) project that you built or contributed to are you particularly proud of / passionate about?

None.

Were you referred by a current GitLab team member?

No.

I once discovered that one of the most effective developers in the world would've had similar answers.


Is there an extension to hide downvotes, ungray all comments, and hide karma count? If not, I'm going to write one.

I know it's just an errant downvote, and people can feel however they want. But the information is no longer useful.


Given those answers, you really seem to clash with gitlab's culture, regardless of how good a programmer you may be.


We also hire people that never contributed to open source but that are great people and are open to our values https://about.gitlab.com/handbook/#values


Yes, thanks for correcting me!


Will you give me a real-world task and see how well I do?

Assessing a candidate is as simple (and as hard) as that. Watching someone while they code isn't useful. https://data.triplebyte.com/take-home-interviews-d7f7ea13067...

Just give me something real to work on.


We give you something real to work on but we'll be in a Google Hangout to discuss it with you: "As part of our interviewing process, you may be asked to pick an issue from the GitLab CE issue tracker, and code ‘live’ with the interviewer there to talk with and collaborate with."


For an in-house installation, it would also be useful to have an editable front page of some sort. Here, you could publish notable projects, or perhaps the ones most sought after. It would also be a channel for news, faqs, etc.

I created an issue at https://gitlab.com/gitlab-org/gitlab-ce/issues/13239.


Thanks, you can use the branded login page for information in the homepage https://gitlab.com/gitlab-org/gitlab-ce/issues/11489


Issue search has a lot of room for improvement. All terms in the search query must occur consecutively.


Totally agree, I hope it will get better after we enable Elastic Search on GitLab.com in a few days.


Totally agree on the project discovery bit. Noticed the same thing when I played with it. I added a couple tickets to try and encourage them to fix it.

* Increase the prominence of gitlab hosted projects on about.gitlab. Project search, trending, curated lists. - https://gitlab.com/gitlab-com/www-gitlab-com/issues/558

* Trending project data by language (js, ruby etc) - https://gitlab.com/gitlab-org/gitlab-ce/issues/13475

* Allow projects to flag themselves as looking for contributors - https://gitlab.com/gitlab-org/gitlab-ce/issues/13502

Give them a +1 maybe they will put resources on making gitlab more oss friendly


Thanks you for creating those insightful issues, much appreciated.


That will definitely hurt the FOSS community adopting them, but they're becoming very appealing for private projects. At work I use BitBucket, but GitLab now has better looking Issues, and with built-in CI it's becoming hard for me to resist switching.


For https://robigalia.org/, I decided to go with GitLab for a few reasons:

1. Free software needs free tools (I did not consider GitHub or Bitbucket at all).

2. Excellent team management and access control.

3. Excellent integration of their CI in the interface, with ability to run own build servers ("runners", in their jargon). This is critical, because setting up the toolchain needed to build takes some time, and I can use the beefy hardware I already have, without having to setup jenkins.

4. Lovely UI.

The only real alternative in this space without setting up custom infrastructure is Savannah.

Or, if willing to compromise on principles, GitHub, which has a lot of incremental downgrades compared to GitLab.


I can't tell if there is a real shift, I would say no. GitHub, in a lot of people, is synonymous to Git. GitLab is superior in a lot of ways, more feature, open source, very open as you pointed out. Their pricing model supports free private repos. Not sure what it would take to really make people reconsider GitHub as the default goto place to host OSS repos.


"GitHub failing hard".

GitLab is great, but it's kind of a copycat project. Nothing wrong with that, it's just there really isn't a compelling reason to join beyond "less-predatory pricing".

And the people who care about that use private repos, not OSS.


> predatory pricing

I've always thought GitHub's pricing is awesome and very accessible. Can you explain?


It'ss quite bad for my company. We have to pay per repo and we like to create quite a lot of small libs and microservices. I'd like to have a option of per user payment.


Very similar here. My startup is 3 years old with ~10-15 developers, but we make many small repos -- about 150 in that amount of time.

Even though it's not tons of code, GitHub's pricing breaks down horribly in this case. I think that that in the long run many startups will move to embrace GitLab in the early days for price if nothing else.


Ah hah, that's interesting. Yep, the per-repo metric does weigh more heavily on architectures based on smaller more granular projects.


Suppose you are a web agency. Every single project for every single client should be version-controlled, right? But that tends to quickly add up when using GitHub - about a dollar per project per month.

So, if my company finishes 30 projects per year, we'd be paying $360/year to GitHub for what is essentially "storing a backup". And if we do this every year, that's $1000/year within 3 years. Not to mention that for "Organizations" the prices are doubled. For some reason. So... $2000/year?

Right now the same job is done by a $5/mo linode, with the prospects of upgrading to $10/mo.


For example, a lot of people complain about issues on GitHub. GitLab handles those much better, that could be a compelling reason to move, but somehow it doesn't seem to be enough.

Private repo can be useful for early stage of OSS projects.

Agreed though that it still feels too much like a clone of GitHub. The UI for example is way to close to the original.


Having used both there's more than enough in either that's bad to justify a switch to the other if you really want to. I personally prefer github's warts to gitlab's. In particular, I find that general site navigation on gitlab is quite tedious and it rarely centres useful information first. But that is very much a qualitative and not a quantitative complaint.

The main thing I find extra useful on gitlab is the ability to mark a MR as a WIP.


Glad you like our WIP function. Do you maybe have any suggestions how we can make navigation better and/or examples of pages where you are missing information?


The decision of what does and doesn't go in the sidebar is very non-intuitive (sometimes what I want is in the sidebar but sometimes it's in the main page). For example, in groups and user profiles you can find the list of projects in the main body of the page (and it's not visible immediately). Why is it not in the sidebar if you have a sidebar? And then the ordering is also a bit weird -- I don't think many people would consider the order in GitLab to be "in order of importance" or even "regular use". And why can't I see the set of files in the repo when I first open it? This is something I feel GitHub does better -- things are much faster to access and IMO much more intuitive.


Thank you for your feedback.

> The decision of what does and doesn't go in the sidebar is very non-intuitive

We try to put top level navigation into sidebar and everything else in the main page. For example navigation to `Projects` is in sidebar however tabs to switch between starred projects or personal projects is in main body.

> For example, in groups and user profiles you can find the list of projects in the main body of the page (and it's not visible immediately). Why is it not in the sidebar if you have a sidebar?

Good example. Agree its still non-intuitive in some places. For you particular example we created an issue to fix - https://gitlab.com/gitlab-org/gitlab-ce/issues/13480.

> And then the ordering is also a bit weird -- I don't think many people would consider the order in GitLab to be "in order of importance" or even "regular use"

Ordering of projects is either by last activity or alphabetically. But in any case there is usually a dropdown in UI to sort by other criteria.

> And why can't I see the set of files in the repo when I first open it?

You can set what to see first at https://gitlab.com/profile/preferences page. We believe README is something people would like to see first we allow users to set different default page based on their preferences.

P.S. Thank you very much for your feedback. It will help us make GitLab UI more intuitive.


Thank you for your feedback, we aware about these issues and already working on improvements on our side, stay tuned!


Thanks, I've asked our UX engineer to look into this.


That would be nice.

In GitLab today, we end up deleting and re-creating merge requests, or waiting until <requester> comments "@<reviewer> ready for merge".


Why do you need to do that? Have you looked at the merge request approvals feature https://about.gitlab.com/2015/07/29/feature-highlight-merge-... (EE/.com only)?


It's not about the number of approvers (just one), but more the approver knowing that the submitter is done making revisions. Usually after the first merge request, we do code review then wait for revisions, that's when the tag happens.

Now this would be awesome:

> We’re thinking about more improvements to the Merge Request Approvals, the main improvement being automatic suggestions for reviewers, based on the history of the changed files in the merge request. For instance, if Jane worked a lot on a certain class and you submit a change to that class, Jane gets suggested to approve your merge request.

Today we are using the self-hosted community edition though.


To indicate that the submitter is done making revisions I advise to remove the WIP indicator http://doc.gitlab.com/ce/workflow/wip_merge_requests.html this feature is available in CE and EE.

If we start recommending automatic reviewers based on the blame this would likely be an EE feature.


And also remember that you can host public repos for free too on Gitlab.com


I believe every Techstars batch does a tools survey across batch companies (at least R/GA Techstars in NYC did) then emails everyone the summary with bar charts.

The one I have is mostly about analytics, sales, and support tools, and unfortunately repository hosting wasn't a question asked. I also wish they would make this data source public so others could see shifts early -- for example the wave from HipChat to Slack would have been very visible.

Perhaps StackShare might be the closest open source of similar data.

http://stackshare.io/code-collaboration-version-control


Personally, I have moved away from Github because I'm finding Gitlab Flow to be more useful. It enables collaborators to have a kind of Gerrit/Critic work-flow to review potential merges without having another system to integrate.


I'm not sure if anyone can answer that question.

Personally, I hope we can eventually move to a federated system, perhaps one based on ipfs.



> Gitlab seems to be much more open about their development than Github, and has a real sense of community

Yes. They didn't just slap an open source licence onto their software, they actually follow an open source development mode, and work out in the open.


The biggest feature that Github provides is its popularity as a central meeting ground for project discovery and collaboration. Some people are only looking for git hosting and don't care about the community aspect, so they could jump ship to Bitbucket or Gitlab.

In that respect, if you're looking for a social network to keep in contact with a general group of people, Facebook is the way to go, and not the myriad of smaller sized social networks. If you're only looking for communication with a small group of people who haven't committed to anything, then you could jump ship to Google+ or whatever. Size of community is the salient feature, not the app.


Facebook is not for me. Msybe its because most of mine freinds are party people. I feel very isolated. I rarely go on it and I find github the only social network I really care about. I feel as though its not really that social though since I only get to talk to people when I bring something to eat the table. Big node repos +1s, the I barely use the follow feature despite having access to some of the most prolific programmers of my time. I want a social programming network. No idea what it looks like, but github has definitely helped curb the isolated feeling. I havent played around with gitlab enough but Im sure it has more potential


We're super excited with GitLab 8.5. It's much faster, no matter the size of your instance (but especially for larger instances).

The Todos, ability to revert commits and CNAME support for Pages, are things that have been much requested and we're happy to have now.

As always, we're here if anyone has any questions about anything.


Pages are an EE feature, but one which is useful for open source projects. Would you accept a pull request for a community implementation of Pages? or would a fork be needed in this case? How do you see this sort of issue playing out?


This is a very good question and something I'm always concerned about when it comes to open core products.


Good question, how we deal with that is detailed on https://about.gitlab.com/about/#stewardship Please let me know if you have any questions.


Hi Job, does this mean it is also faster in low memory environments like 512M? ToDo integration is a great feature!


No, unfortunately not. We recommend 2GB of memory to run GitLab https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/inst...

If 512MB is a requirement for you please consider using Gogs.

Glad you like the Todos feature!


I just wanted to say how awesome it is that you mention Gogs, a competing platform. It shows that you're focused on your domain, not closed-mindly discounting every competitor, and are open about any shortcomings in Gitlab.


It also makes sense from a business point of view. The three strong points that I've taken from business school are:

1) You can overtake an incumbent if you can offer twice the value at half the price. If you can produce a drill that works two times better than existing drills at half the price, you'll overtake the drill market.

2) You can't compete with "as good as". Winning here is more marketing than anything and this is where companies like Apple and Coco-Cola shine. You can't beat Coke with point one, since it is impossible to produce something that is better than Coke. You can measure the performance differences between drills, but you can't measure the psychological value of Coke and Apple

3) You can't compete by price, unless you are dealing with a commodity product, which brings me to my point for posting.

Turning "Git hosting" into a commodity product is not a bad situation for GitLab and I honestly think this is where it's heading. In a year or two, we'll probably see less tangible/understood things become the main selling point. Such as intelligent code reviews, better code management metrics, defect predictions and so forth.

Edit:

Forgot to mention that point 3 is also where Atlassian deserves a lot of credit. They are leveraging point 3 and trying to parlay it into point 1.



Perhaps this is what you were thinking too -- it'd be stellar to be able to run on a t2.nano or the DO $5/mo box, but it's also easy to understand why that wouldn't be a major priority for the GL team.


We would love to make this happen but there is so much functionality in GitLab it needs a ton of memory to run.



It seems not, unfortunately, I'm sorry if you were waiting for it.

I'll discuss if we can ship it in a patch [0], otherwise it'll land in a month in CE.

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/11489#note_38...


Thanks, Looking forward to it.

otherwise, congrats on another release!


Thanks!

Consensus seems to be we can ship it somewhere this week.


I've been keeping an eye on that issue thread throughout the morning and although it doesn't seem appropriate for me to make a comment over there just to say this, I wanted to communicate it somewhere: the gitlab team is really impressing me in terms of responsiveness and flexibility. I really hope to see you keep that culture as you continue to grow and succeed. It doesn't go unnoticed!


Thanks, glad to hear that. We're doing everything we can to keep and improve upon that culture. Being remote first and having a public issue tracker certainly helps, less difference between a comment of a co-worker and of a user.



Sorry about that. There was a brief interruption to GitLab pages while we fixed a vulnerability. It is back now https://twitter.com/gitlabstatus/status/701897151790653440


Is this release going to make any significant difference on the hosted projects? The last time I asked about Gitlab.com in a thread people mentioned that it's not more popular due to performance issues.


Yep, so that is what we solved in this release. Title of the OP: "GitLab's fastest release ever". For more details see the announcement and https://gitlab.com/gitlab-com/operations/issues/42


Have you deployed it to gitlab.com?


Not yet, from the OP: "For GitLab.com users: We plan to enable custom domains on GitLab.com in the following week, so stay tuned!"


I've moved all my private repos to Gitlab based on the chat on here and other places recently RE Github, Gitlab, and other solutions.

I'm very happy overall, the interface is great. It's a bit slower than github currently (the web interface) as I'm using the online version rather than self hosted, but apart from that it's really bloody good.

I'll be recommending it to others going forward and using it for all new repos that I want hosted.


Thanks, that's good to hear.

We're working hard on making it faster, this release being a major milestone in that work.

Last release, we started shipping a performance monitoring tool [0], to make it easier to see what exactly is slow.

[0]: https://about.gitlab.com/2016/01/22/gitlab-8-4-released/


Yep, also see our 'Make GitLab.com fast again' issue https://gitlab.com/gitlab-com/operations/issues/42 for updates about performance.


Nice, I'll take a look.


What procedures did you follow to move your private repos over? I have been using private, self hosted git for years now. Were you able to move things over and keep commit history? (since I guess that's the only feature I currently have.)


I just added Gitlab as a new remote, and pushed. Easy as that. Keeps the entire repo history. I then just removed my old Github remotes.


Thank git for a model that 'allow' migration through a primitive operation.


Apart from the other methods mentioned here (such as the import from the user interface http://doc.gitlab.com/ce/workflow/importing/README.html) is also an import rake task http://doc.gitlab.com/ce/raketasks/import.html for administrators.


If you move your repository by importing it (in GitLab UI, under new project) or just by clone + pushing it yourself, you will always retain your entire commit history.


If you import from GitHub, your issues, PRs, wiki and all code will be imported.


It would be really cool if GitHub stored issue, PR, and wiki information in the main Git repo. That way all of these things would be very easy to keep in sync across different services.

I've had this idea for a while now. I wonder if it would be practical and if anyone has ever tried something like this.


As a separate root branch, it would work nicely. There are huge benefits also in that you get an inspectable history of issues. From GitHub's perspective, it would be more difficult to authenticate issue changes—they'd need signed commits and pre push validation, right?


That's what Joey Hess' github-backup does: https://github.com/joeyh/github-backup

It's one way, though, you can't create a new Issue or PR by just updating repo.


That would be cool, we're discussing distributed code review and issues in https://gitlab.com/gitlab-org/gitlab-ce/issues/4084


Is there an issue/PR migration path as well?


If you use our GitHub importer, it will migrate your code, wiki, issues and PRs. It can do it in batch for all your GH projects.

Docs here: http://doc.gitlab.com/ce/workflow/importing/import_projects_...


I guess it's good if you just want private stuff, but if you want to build portfolio type thing or want discoverability private stuff isn't ideal


No problem, just click the "Public" radio button.


Their performance graph shows response timings up to 25 seconds [1]. GitHub's mean web response time goes up to 200 milliseconds. The difference is two orders of magnitude. Is GitLab really that much slower?!

[1] https://about.gitlab.com/images/8_5/issue_timings.png [2] https://status.github.com/


Note that this is 95th percentile and the peak is _before_ the changes of 8.5 _and_ that this is data of GitLab.com that has problem not typical for a GitLab instance.

That said, we're fully aware of the shortcoming of GitLab.com. It has been slow and unresponsive. We're working hard on improving it [0] and this release has been a step in that.

[0]: https://gitlab.com/gitlab-com/operations/issues/42


That's the 95th percentile, not the mean. This means that 95% of all transactions completed _within_ the time, with only 5% exceeding it. Right now our 95th percentile hovers between 1.5 and 2 seconds, the mean hovers between 500 and 700 ms.


GitHub's 98th percentile is still just 414ms though. So you still have a lot of catching up to do.


We're aware. GitHub did an amazing job on scaling GitHub.com. We'll get there!


Your 95th percentile ought to be 200ms. That's the standard that Google set for itself a decade ago.


It is extremely slow. We tried it on a 1go droplet and it felt slow with 2 users but can't beat that £0 price.


Just so you know, we recommend a minimum of 2GB https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/inst...


Have you tried running GitHub EE on something of the same spec? It's terrible to near impossible and it doesn't include nearly as many of the features as Gitlab. We have been running Gitlab for 100~ employees for well over a year on a single, medium/low specced VM and its lightning quick, so much so that when Devs/Ops have to use GitHub you can hear the sighs around the office!


> medium/low specced VM

Can you be more specific? Does that mean 1core+512MB? Is 8core+12GB considered medium to you? Is that 100 Programmers or 50 Programmers plus 50 issue commented?

Totally agree on GHEE. I have 4 Programmers+4commenters running on a $200/month recommended hosting partner and it's performance is not up to my expectations (especially when I'm the only one on...)


Glad to hear GitLab is fast for you! Will be even faster with 8.5 :)


Seriously Sytse, Gitlab has not only continued to improve, it's done so at rockets pace while (and here's the hard part) at the same pace also improved quality and test coverage.

Do you remember a year or so ago when I was whinging about some regressions after several upgrades? Well I'll tell you what - there hasn't been any that have impacted us in such a long time upgrades - even to a major version - do not worry me one bit and our Devs are always excited to see what's new.

I'm not sure if you remember but we're a non-profit, charitable organisation and GitLab has really helped us immensely over the past year.

A damn fine product from a damn fine team, supported by a damn fine community.


Thank you for your kind words. I'm very glad to hear our quality is improving and you're having pain-free upgrades.

We're proud that GitLab allows everyone to contribute, even organizations without a large budget https://about.gitlab.com/strategy/

Thanks for using GitLab and writing about it https://smcleod.net/mirror-gitlab-to-github/


When I met Gitlab, 3 years ago, I didn't expect this. The product is so much mature, the UI is so much better and the feature-set increased too. I respect these guys. The competition is though out there. Github is _the_ place where many git users started and is the _de facto_ standard for open-source/show-cases or even tech blogging, these days.

There are a few things that annoy me as a Gitlab user (UX things), apart from the search/responsiveness of the application. Moreover, they improved _a lot_ the installation/upgrade process over these years. I'm expecting big things from you now :)

Anyway I need to say that these guys have been working a lot and deserve much credit. Kudos for you, guys!

One of the things that annoys me most is that the homepage of the repository, where you have the README is not the same where you have a file browser (Perhaps this is Github-biased, but is soooooo much better. Think about it :)


The only thing preventing me from using Gitlab is that someone registered my username. I'm "echelon" on Github, Twitter, Gmail, and dozens of other services. I guess I missed the boat. :/


Thanks! We think the displaying both project information and the files is too messy, but I can see you point. If you have any other UX suggestions feel free to share them.


I love GitHub, I'm loyal and grateful to them for all they've done for us, but GitLab is significantly more agile these days and loyalty easily can be reassigned. Even Bitbucket is picking up development, so, if I was GitHub, I'd really seriously reorg and ramp up development and innovation!


Nitpick:

> GitLab no longer loads large Git blobs (e.g. binary files) into memory when browsing a Git repository. This prevents timeouts and memory leaks.

Nope. Not loading something doesn't prevent memory leaks. It might make existing leaks not as bad (because you're leaking less).

Either you're not leaking at which point it doesn't matter how big the thing you load is, it will get freed once it's not used, or you're leaking at which point, yes, if you only load small things, you get to run for a longer time before you die, but you will still die eventually.

Only loading smaller things doesn't plug leaks.

Aside of that: This looks like a very impressive release. Congratulations!


Nitpick on the nitpick. If the Git blobs were the source of the memory leak then this would, in fact, fix the memory leaks.

Pretty aggressive stance when you may, in fact, be wrong.


> If the Git blobs were the source of the memory leak then this would, in fact, fix the memory leaks.

no. Because they are still reading git blobs - just only for the smaller files.

> GitLab no longer loads large Git blobs (e.g. binary files) into memory [emphasis mine]

So if their handling of Git blobs is leaking memory, then not reading the bigger blobs just gives them more leeway before they crash.


Again, you may still be wrong. Many systems have different strategies for large blobs vs. small blobs (I know it's many because I've written several myself) including chunking strategies, separate memory pools etc.

I'm taking this stand because I've had the exact issue we are arguing about: my large file handler had a leak in the memory pool for large blobs. Basically it was shared memory space for multiple processes so large objects could be passed out of band instead of using IO.


Thanks for the nitpick, always welcome. I'm asking the author of the change what the background is on this. Will update the post if I can be more accurate.

Thanks!

UPDATE: Technically we're not fixing the leak, but this fix is reducing the impact significantly.


I think you can be a bit more charitable in your interpretation.

Think of it this way: By no longer loading large Git blobs, it prevents known memory leaks and prevents known timeouts.


Great job GitLab team! Way to go! Unfortunately I cannot use it for my projects till the issue https://gitlab.com/gitlab-org/gitlab-ce/issues/12920 exists. Hopefully, it will be resolved some time in the future.

I am firm believer in FOSS and I am very glad with GitLab embracing it as much as possible without affecting their revenues. I have started creating my new repositories on GitLab from this month


Thanks! I see I already commented on your request 20 days ago and I've left a new one just now. Cool that you have started creating your repo's on GitLab.


Was 8.5 able to address either of these?

Large commits can't be viewed:

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

Users created via LDAP login continue to count towards the user-count even if the LDAP account is deleted:

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


Thanks for asking. For the first issue work is being done but we need more time https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2705

The second issue seems more like something that could become a feature request than a concrete proposal. Consider leaving a comment in the issue with your proposal.


In EE there is a nightly LDAP sync worker that will auto-block any LDAP users that are no longer in the directory. This should address the active user count issue for licensing.


I just upgraded and the diffs are WAY faster now. Thanks so much for all of the hard work!


That's great to hear. It's a big community that makes this happen.


Just curious, were there any new changes made to branch creation and protected branches? I'm getting a

Branch creation was rejected by Git hook

When trying to create branches via my gitlab instance and it seems to take a lot longer to process the request. Pushing via a command shell seems to work well.

--update I just rolled back my version to the older version and see that all of the branch functionality via the gitlab site works okay.


I'm not aware of any changes that would explain that error, but that doesn't mean it can't be a regression in 8.5. If so please open an issue for it and link from https://gitlab.com/gitlab-org/gitlab-ce/issues/13350


> With GitLab 8.5, we’re offering GitLab Geo as an Alpha to all our Enterprise Edition customers. Once GitLab Geo has left Alpha / Beta state, a special license will be required to use it.

I'm not sure I like this trend.

While I understand some features GitLab may feel its worth a "second license" fee, it sets a bad precedent.

Similarly, I don't want to give you $390/year for a GitLab instance with 2-3 users which keeps me from paying for the stuff I use for sideprojects. Although, tbh, if you are going the secondary license route for various features it seems I'm better off looking into an alternative and just implementing them myself.

I honestly was just using the post-receive hook, etc. for this sort of thing.


We will make it possible to buy a license for n users, rather than n*10 users (as noted below).

If you're not interested in GitLab Geo, you won't have to pay for it, while maintaining all other EE features.


afaik there will be possibility to get a license for n users instead n*10 packs.


That's correct.


Thanks for that.

Can you give us details on when this change will happen?


We're not sure yet when it will happen, but we'll make it clear when we do.

Update: our aim is before Q1 ends.


Great, thanks for the update.


When I go to github, there's a search bar at the top to search for the public repo I'm looking for.

I can't find the search feature at gitlab.com. How do I search for users or public repos of interest at gitlab?


Use explore to search for interesting projects (and the people that have them in their namespace): https://gitlab.com/explore

Press `s` to search for anything. However we only support search for people in places where you immediately need them, like when adding to a project.

I created a feature proposal to also search through people: https://gitlab.com/gitlab-org/gitlab-ce/issues/13672


Ok. I followed the Explore link, but I cannot find the search field on that page. It seems to only allow me to browse by trending/most-stars/all. Hitting 's' key on my keyboard doesn't seem to change the page in any way. Am I missing the search field?

(Note, this is using Firefox/Iceweasel 44.0.)


I think you must be logged in to see the complete UI (with search field)


Indeed. The search field is currently only displayed for users that have logged in.


Thanks, that doesn't make sense so I made an issue to remedy it https://gitlab.com/gitlab-org/gitlab-ce/issues/13676


Update: we'll ship this fix with 8.6. It has just been merged.


Great!


Still using redmine + gitolite here but have been watching Gitlab for a while, in fact I tried it yesterday and it's still quite resource hungry and slow(using DO's default installation with 1GB memory).

Redmine+Gitolite has nearly everything I need but Gitlab's code view interface is better. Redmine's backend seems running more efficiently but its interface is not modern enough at this point, especially on how to review git repos.


gitlabs minimum requirements are 2G of ram (although that's for 100 people).

Without trying to appear as if I'm defending gitlab itself, I've always been of the notion of "Do it right and then do it fast".

This is how postgresql is starting to beat the ever-loving crap out of mysql now, it used to be the slow option, now it's the one that wont eat your baby.


Thanks, we indeed recommend 2GB for all installations https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/inst...

I've made it a bit more clear in https://gitlab.com/gitlab-org/gitlab-ce/commit/b31c68aa2afbb...


Much faster! I notice it's rendering large source files instead of displaying them as binary now, so great!

One issue: I'm getting a really weird animation/hover over effect on the Gitlab icon in the upper left corner. Is that meant to happen? Is there a way to disable this.

Other than that, everyone should upgrade to this version.


Glad to hear that the rendering got better for you.

That animation is our loading indicator introduced in GitLab 8.4. There is no way to disable it. However, it seems to have a lot of fans https://twitter.com/jerbob92/status/692089402030460929

I hope it is less weird now that you know what it is for.


Rendering is flawless now.

I figured it was for loading, but I still don't like it (and it renders very strangely in Safari -- try mousing over it).

I would really like the option to disable it. I'm sure others like it though, cool option to have.


Thanks for the feedback. We have an issue for the Safari rendering in https://gitlab.com/gitlab-org/gitlab-ce/issues/13645 Consider making a feature request if you want the option to disable it, but in general we try to prevent the complexity of options as much as possible.


We're bringing the option to customise the interface to CE. If you run your own instance, you can replace the logo to disable it.


Thanks, will do. Looking forward to the interface customization options.


Great! Docs for the branded login page are at http://doc.gitlab.com/ee/customization/branded_login_page.ht...

The merge into CE is happening in https://gitlab.com/gitlab-org/gitlab-ce/issues/11489 and hope it will be in one of the 8.5 patch releases.


I'd love to try GitLab out, but the OSX installation instructions [1] are a bit of a put off. I'm not even sure if that's the right URL, but it's where google takes me. The instructions refer to a "runner"; I'm not really sure I understand what that is, and it's not explained anywhere. The "ci" makes me think this is something to do with continuous integration, so I'm really not sure if this is the right thing to be looking at.

The instructions also say "(In the future there will be a brew package)"; this is sorely needed!

[1] https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/ma...


I'm sorry this is confusing. We're working on a better, more clear website. You were looking at the CI Runner, which is a part of our Continuous Integration.

Simply go to https://gitlab.com/ and click in the top right to sign up for a free account. You can use that instance or set your own up by following the instructions at the download page [0].

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


GitLab itself doesn't run on OS X. To try it, you can simply sign up on gitlab.com, it runs the enterprise edition.


It's a waste of resources but you could run it in a vm with or without docker.


Find the official Docker image here: https://hub.docker.com/r/gitlab/gitlab-ce/


You're reading the docs for the continuous-integration runner :)


I did suspect as much, but it's the first result when I google "gitlab OSX" and it's titled "Install on OSX - GitLab".


Whenever you feel lucky, don't assume you are... ;)


Can i use dnf update on fedora to update the gitlab package if I have the repo installed? I am on fedora 23 and doing dnf update doesnt upgrade gitlab. Also doing a dnf install gitlab-ce gives me a message that gitlab-ce-8.2.0-ce.0.e17.x86_64 is already installed.


It worked with rpm so I assume dnf should work as well. Maybe you have to update your sources first since we have our own package server? If maybe you installed the package by downloading instead of adding the source server? Consider following the instructions on https://about.gitlab.com/downloads/ (the main instructions, not 'select and download the package manually and install')


Very easy upgrade from 8.4.3 to 8.5 on Ubuntu using the omnibus packages. I did have to install bundler in my system Ruby (I have RVM on the system; the install scripts executed via apt-get apparently doesn't care), but that was the only hiccup.


You should not have to install bundler on your system to upgrade to 8.5. If someone else encounters this please open an issue so we can diagnose the problem.


Here's my console buffer from the installation: https://gist.github.com/cheald/6002dbe275a379a5f85a

tl;dr: apt-get install gitlab-ce failed with "bundler not found". rvm use system; gem install bundler, apt-get install gitlab-ce and it worked fine.


Just to be clear. All we need is the output from the console not the actual backup.

What I see from the result your getting is the actual backup command failing. From my experience this might be do to how its executed through the upgrade process and we can have a closer look at what failed when running the create command.


I sent an email, but it looks like if RVM is installed, gitlab-rake may be depending on bundler being installed in the currently-active RVM environment. It looks like RVM may be conflicting with gitlab's bundled Ruby due to RVM setting GEM_PATH and prevents bundler from being found, which causes the upgrade process to fail. Explicitly setting GEM_PATH for the gitlab_rake invocation may fix it.

If bundler is available in the active RVM environment, it works fine.


Correct the GEM_PATH is conflicting. Thank you for the information provided and your help through our support channel. Here is the public issue for future reference: https://gitlab.com/gitlab-org/gitlab-ce/issues/13689.


Can you create a backup with sudo gitlab-rake gitlab:backup:create and send us your results to support@gitlab.com? Please mention its coming from this thread.


Thanks, we'll look into this.


Another great release in an incredibly fast turn around time, well done to the team and everyone that's contributed.


Are there any blog posts about techniques used to improve performance you guys would care to share? Thanks!


Not yet, but I've been thinking of doing so. The difficulty is that you basically have to write the blog post (or at least take a lot of notes) while solving problems as otherwise you'll end up forgetting all the intricate little details.


That's fine, I'm just curious because you usually learn a great deal. If anything the biggest performance changes could be nice, though it may mostly be small tid bits here and there (though large overall). Thanks for all you guys did!


I still have a bunch of notes laying around from the changes we made for 8.5 so I'll take a look at those. For future changes (except maybe small ones) I'll see if I can just write down 1 or 2 sentences what I did _after_ I did it, stringing together a blog post from that should be easier than doing it from scratch.

I created an issue about this so I won't forget: https://gitlab.com/gitlab-com/www-gitlab-com/issues/568


Thank you very much, learning from others is an invaluable way of learning to improve code and write code with a improved approach. Also a great way to try and avoid bugs when your code reminds you of a reported bug. Thank you again! Will look forward to reading future detailed development blog posts, it wont have to be every single little detail, but those small things that make a difference are handy to read over. Thanks again!


Awesome!


> yes, all important things for those of you that speak Spanish or Portuguese

What do they mean by that?


I'm Brazilian and needed a few seconds to understand what they meant. I kept reading it like to-do(s). In the end they're just playing with the word:

https://translate.google.com/#pt/en/todos


Thank you for making me click. That's such a bad pun.

(I'm Brazilian too)


I'm sorry, I thought it was hilarious.

We wanted to acknowledge some people's frustrations with our chosen way of writing Todos.


It's a Spanish/English pun.

Todos means "all" in Spanish, so "all important things"

But also Todos as in multiple Todo items.


>Not only have we increased performance for everyone, getting to what is important is now super quick with Todos

todos means all/everything in Spanish and Portuguese.


Impressive release! Is there a guide on migrating from install from source to using omnibus? We currently upgrade from source but would like to move to omnibus.


Thanks!

To upgrade from source to omnibus: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc...

To see all our update guides: https://about.gitlab.com/update/


Warning as someone who just did that. MySQL is EE only on Omnibus. I switched from Source (MySQL) to Omnibus only to find that MySQL was EE only.

So I had to go back to Source.


You are correct, we only ship our Omnibus packages with PostgreSQL. And the ability to use an external MySQL server is only in the Enterprise Edition.

Switching away from MySQL might not be an option for you but documentation on how to convert from MySQL to PostgreSQL can be found on https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc...


We recently switched from a source package using MySQL to the omnibus package and the migration to Postgresql was really easy and went without a hitch.


Glad to hear that, we try to keep the conversion instructions up to date and have tested them extensively.


Maybe a stupid question but is there a publicly hosted GitLab that provides free repo space (and the usual pay for private repos) or is it only self hosted?


https://gitlab.com/ with free public and private repositories


Ok I didn't see that. The rest of the copy on the (particularly the pricing page) seems to indicate it's only local.


There is no pricing information there because it is free with forum support. But I agree it is confusing and made https://gitlab.com/gitlab-com/www-gitlab-com/issues/567 to remedy that.


Two releases ago, updating was a bit of a pain for me, so I guess I'll wait until Friday with this one. Anyway, the new features sound really good!


What was painful exactly?


First upgrade for me (8.4 -> 8.5)

On a pretty small instance (1.7g ram google cloud) + 1gb disk swap the omninbus update failed with out of memory. Added some more swap space and it finished fine. It's probably not powerful enough to run it though.. Just a heads up.


I'm sorry to hear that. We advise a minimum of 2gb of ram, so I'd expect it run successful for you. I created an issue on the omnibus issue tracker about the memory requirement for upgrades, here: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1135

I'm glad you managed to solve it, though.


Still waiting for issues priority levels. Without it, the issues page is just a mess.


Thanks, I created an issue to discuss this. Would love to get your input.

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


Nice, looking forward to the upgrade to GitLab pages on gitlab.com !


Thanks! Should be soon!


Will there be a possibility to use an apex domain ? Looking to switch from GH Pages.


Yes. Sure. Instead of adding the CNAME you need to add an A record. You can get the IP address with dig: $ dig a myuser.gitlab.io

Then configure your domain to point to that IP address.

We are currently working on documentation covering that part too.


Brilliant, thank you (and sytse below) for a prompt response. Looking forward to set it up.


I'm not sure and asked Kamil to look into this.


Awesome that theres a release.. but just as I'm migrating from one server that it has it built from source to a new one that uses the omnibus package.


This comment is not meant to be the main judgment on what is otherwise an interesting update, but:

> To focus on your content

shows a screenshot with extremely long text lines that are far harder to read than than when the sidebar thing helps keep the lines to a still-too-long-but-not-as-bad length. How does nobody at GitLab realize that you need some max-width or a container or something to keep text line length comfortably readable‽

(the same can be said for Hacker News, but everyone seems to know that it's ugly already)


There's already a setting for that http://imgur.com/GftE0Wx


well, that's something but 1200px width is still way too long for optimal reading of lines at that font size.


it does look like it says MAX 1200...but i could be mistaken.


You're right. And that means the only way to set it to keep text contained less wide than that is to have a smaller browser window.


I imagine the fact that not everybody cares about the length of lines is a factor. I keep hearing people complain about various wide articles, but I've never noticed any problems reading such content myself. Thus having some small max-width definitely isn't a universal requirement.


Uh oh, here comes the "max-width = readability" cargo cult.


"cargo" cult??? Don't you just mean "cult"? How does this have anything to do with cargo cults even metaphorically?


The "cargo" is self-referential, clearly. It's a cargo cult "cargo cult".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: