
GitLab 11 released - markdog12
https://about.gitlab.com/2018/06/22/gitlab-11-0-released/
======
chinhodado
Another release, another whole slew of project management features that I
don't know who asked for, while things that I consider basic for a code repo
manager is still nowhere to be seen:

\- batch review (seriously, will this ever be done?)
([https://gitlab.com/gitlab-org/gitlab-
ee/issues/1984](https://gitlab.com/gitlab-org/gitlab-ee/issues/1984))

\- configurable tab width ([https://gitlab.com/gitlab-org/gitlab-
ce/issues/2479](https://gitlab.com/gitlab-org/gitlab-ce/issues/2479))

\- consecutive git blame for current revision ([https://gitlab.com/gitlab-
org/gitlab-ce/issues/37135](https://gitlab.com/gitlab-org/gitlab-
ce/issues/37135))

\- rebase and merge in one single step ([https://gitlab.com/gitlab-org/gitlab-
ee/issues/895](https://gitlab.com/gitlab-org/gitlab-ee/issues/895))

\- unable to view diff for any file that is slightly large
([https://gitlab.com/gitlab-org/gitlab-
ce/issues/30061](https://gitlab.com/gitlab-org/gitlab-ce/issues/30061))

GitLab seems to be trying too hard to replace project management tools like
JIRA and CI tools like Jenkins that it's neglecting its core feature set that
is code repo management.

~~~
grandinj
Paying customers.

Specifically, the person who signs off on Gitlab at a company is generally
some kind of project manager so they value project management features.

~~~
Qwertie
All the extra features is the main selling point of GitLab. It's the reason
you use it over GitHub because GitLab is more than just repo hosting and issue
tracking.

~~~
jlengrand
That, and the fact that you can self-host

~~~
BjoernKW
You can self-host GitHub, too:
[https://enterprise.github.com/home](https://enterprise.github.com/home)

~~~
jlengrand
You can, at entreprise prices indeed. Which is out of reach for most SMEs out
there. This is IMHO a llarg part of what made Gitlab successful.

~~~
BjoernKW
The price is roughly $21 per user per month, which isn't really all that
enterprisey, given you have at least 10 users, that is.

I don't know exactly how GitHub Enterprise and the GitLab Community Edition
compare in that regard but aspects such as usability, maintainability and
updatability are much more important than saving $21 per user per month.

So, yes if your company has a lot fewer than 10 Git users GitLab probably is
the best option. In every other case, it depends and the pricing advantage
becomes less pronounced.

~~~
jlengrand
Sure, Github definitely has worth. I use both myself.

But for a petty price, Gitlab comes with a Kanban board, a release management
system, a (free) CI tool, and all of the newer features I don't have
experience with ( the whole Kubernetes integration lately? ). (So no need for
paid travis, Asana, Jira, ....).

Adding to that that most cloud providers offer ready to use images with Gitlab
installed, I understand what it becomes such a 'default choice' for new
installs lately.

~~~
snappycomeback
Compare apples to apples, at least. The paid GutLab plans are as expensive or
more than GitHub. And they keep raising their prices too cuz they aren’t
making enough money to survive. The big difference for us (Apple) is
performance and reliability. GitLab isn’t reliable and GitHub Enterprise is
rock solid with whatever we throw at it. That’s better than a bunch of
features (to my team, at least).

~~~
ThrowawayR2
> _The big difference for us (---) is performance and reliability._

If that's the name of your employer, bear in mind that you can get into
massive hot water for using it to endorse third-party products without
authorization.

~~~
christmasweater
Ive read about them using both systems. Seems like teams have flexibility to
choose what they want. As they should. And some prefer GitLab.

------
parfe
>GitLab has memory leaks. These memory leaks manifest themselves in long-
running processes, such as Unicorn workers. (The Unicorn master process is not
known to leak memory, probably because it does not handle user requests.)

>To make these memory leaks manageable, GitLab comes with the unicorn-worker-
killer gem. This gem monkey-patches the Unicorn workers to do a memory self-
check after every 16 requests. If the memory of the Unicorn worker exceeds a
pre-set limit then the worker process exits. *

I know this is a Rails issue, but I cannot believe this is still a problem. I
remember when the RoR folks blamed the Rails memory leaks on Zed, and Mongrel,
more than a decade ago. They were obviously incorrect. Did the community
simply give up on fixing the problem?

* [https://docs.gitlab.com/ee/administration/operations/unicorn...](https://docs.gitlab.com/ee/administration/operations/unicorn.html#unicorn-worker-killer)

~~~
qop
Were you under the impression that Rails has a functioning dev community?

I am very familiar with the rubyverse, and boy do I got news for you.

Rails is to Ruby as the Big Dig is to Boston.

But it's hard to get Rails devs to admit it. They know it, of course. They
live it. They breathe bad code, they exist as extensions of a philosophy that
has failed it's way to the top.

I used to think Zed was a dramatic weenie. Then I got a bit deeper in Rails to
learn how to pursue better exploits. And deeper. And deeper. And finally I
just hit a point where I just wasn't willing to work on RoR-related gigs.

Convention over configuration is one of those ideas that goes great on paper.
And then you start in on some buzzwords and fancy lingo, it's the bread and
butter of selling to project managers. But there is a point where CoC breaks
down at a technical level, and that point is _literally the first moment you
come across something difficult to express_

Rails is weak in doing things ANY other way than the Rails way, and what
developers do (and it's not their fault) is using their creativity and
ingenuity to solve the problem. I believe this is why metaprogramming in Ruby
has such a vocal backing, because there are millions of shims holding up
millions of Rails' shitty choices that depend on method_missing fuckery or
string-based define_method gadgets. In the spirit of what it means to solve
hacker-ish problems, it's great fun to program like that for a while, and then
a year or two down the line you look at that shit and it can really break you
down. Good developers mistake themselves for bad developers because of this,
to be honest.

Zed's probably had the idea to write an entire book of how insanely FUCKED
Rails actually is, but to make the book plausibly thorough would mean a human
being being exposed to far more stupidity than modern science can safely treat
for. It'd be dangerous to have that much stupid intake just for a book.

That unicorn-worker-killer gem is a perfect caricature of the kinda problem-
solving you run into with Rails. Let it die a horrible death, restart that
shit with some logic to let it keep dying predictably.

That technique, multiplied by every component in the system, multiplied by
every developer on the team, multiplied by MVC requiring developers to have to
know too broadly the system they're working on, multiplied by however many
years and Rails versions the project has somehow survived, you approach
something I can only imagine is quite similar to what hell must be.

~~~
TheAceOfHearts
I love Rails for certain projects, but it's definitely true that at a certain
point things start to break down. Maintaining a large complex application with
Rails is not fun at all. ActiveRecord is amazing, until it's not.

IMO, you can still learn tons of great practices with Rails, and for certain
projects I still think it's a great choice... But you have to know when to
drop it and move on to more robust solutions.

Like most engineering tools, it makes certain tradeoffs, and you have to know
how to pick the right one for your job.

~~~
rimliu
At certain point everything starts to break down no matter the stack.

~~~
StaticRedux
You're absolutely right, you're just completely ignoring context. Some things
break down a lot sooner. Eating or drinking too much of anything can kill you,
even water. But drinking acid will get you there a whole lot faster. Rails is
the acid of the programming world.

------
gorset
I feel they're making it harder to review a merge request with multiple
commits. It used to be able to click on a commit and get succinct view of the
actual commit with title and message. Now days after clicking on a commit, you
have to scroll down and skip a lot of irrelevant information to find the
actual commit content - and gitlab by default hides the commmit message! This
makes it very cumbersome to review a MR with many commits, and also harder to
train new developers to learn the advantages of making good commits.

Being able to review per commit in a merge request was a major reason for my
company to choose gitlab back in the day. A merge request consists of a series
of commits, each doing a single change (basically the same way linux's patch
series works: [https://www.kernel.org/doc/html/v4.16/process/submitting-
pat...](https://www.kernel.org/doc/html/v4.16/process/submitting-
patches.html#separate-your-changes)).

I'm hoping gitlab will improve the experience in the future for us that want
patch series style merge requests, but I'm worried that gerrit style
development is winning where the result of each merge request is supposed to
be just a single squashed commit.

~~~
jobvandervoort
Thanks for the feedback gorset. I'm curious to dig a little deeper.

With the irrelevant information, you mean the top part of the merge requests
(ie description, CI status, etc)?

And as far as I can see, in the current version, we only hide the body part of
the commit message.

I think we can make the experience better by autoscrolling down once you click
on a commit in a merge request. I've made an issue [0].

I'm not sure about showing the full commit message. Many would argue that only
the first line summary is crucial to show, which is what we do now. But I'm
happy to discuss.

[0]: [https://gitlab.com/gitlab-org/gitlab-
ce/issues/48328](https://gitlab.com/gitlab-org/gitlab-ce/issues/48328)

~~~
gorset
Thanks for the quick follow-up!

This might be a difference in expectations, where we are talking about two
styles of merge requests. I believe they can be both supported well by gitlab
(in fact, I consider gitlab to be the best review tool out there because it
has support for both styles).

## Gerrit style MR

Mostly a merge request with a single commit. All relevant information is
placed in MR title/description. If there are more than one commits, they are
usually added to review the first commit based on review feedback or problems
detected by CI. The commits are often squashed before merge to master, so the
individual commit messages are secondary to the MR title/description.

## Patch series style MR

A merge requests with multiple commits, each containing a single logical
change. The MR title/description only contains high level information/summary
- more detailed description is found in the commits.

If serious problems are found either by CI or reviewer, the developer often
amends the commits rather than push new commits on top. The reason why is that
each commit should be as complete as possible, which helps reviewing, git
bisect and keeping a good git log history.

This style requires more upfront work by the developer, but the advantage is
that reviewing becomes easier. Instead of reviewing a large diff with many
different changes, the reviewer can look at a single commit at a time. Some
types of changes such as refactor, reformat can quickly be verified and
reviewed because they are not making any semantics changes. A commit
containing a bug fix is much quicker to review if there are no refactoring,
reformating or other semantic changes in the same diff.

Good commits should also have good commit messages, which describes what, why
and why like /this/. Just as important, this information should be easily
available when reviewing the merge request. It should be easy to iterate
through all the commits in a merge request, reviewing both the commit message
and the commit diff for each commit.

With the latest changes of gitlab, I feel it's being optimized for Gerrit
style merge requests, in which case your comment make sense that you're not
sure about showing the full commit message. However, for me this is a major
step back since we do patch series style merge requests where each commit is
often reviewed individually.

~~~
jobvandervoort
Thanks gorset for the great response and the new insight you gave me into
this. I now understand what you mean and see how the changes have negatively
affect patch-series style MRs.

I created an issue on this and I encourage you to contribute there as well:
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/48334](https://gitlab.com/gitlab-org/gitlab-ce/issues/48334)

We're not fans of adding additional configuration, but I can imagine we store
e.g. what the last state was that you left commit message in, as to not have
to unfold it every time. I'm sure you have further thoughts on improvements
that can be made.

------
whafro
We've been paying for GitLab for about a year now, and it's mostly been a good
experience. There have been three things that seem to come up weekly for us:

1\. Lack of traceability/auditability. We're in healthcare, and have a
regulatory burden that requires versioning of basically everything. GitLab
does this for code and wikis (thanks to git itself) but not for issues, merge
requests, comments, etc. I've ended up building a service that just ingests
the webhooks for these to store them away, which feels ridiculous. Since the
webhooks for comments doesn't get triggered on update, I even have a TRIGGER
shimmed into GitLab's postgres DB. Ech.

2\. There's no concept of a bot user, so every integration we want to do is
against a single account/identity, in part because...

3\. The pricing of Ultimate feels ridiculous, and that's the only way to get
something as fundamental as epics. $1000+ a year for every employee?

[edit] $1000/mo -> $1000/yr. (per month would have been even more way cray)

~~~
jsty
> $1000 a month for every employee?

Typo? Pricing page [1] lists it at $99/mo

[1] [https://about.gitlab.com/pricing/](https://about.gitlab.com/pricing/)

~~~
whafro
Thanks, edited!

------
flavor8
I haven't checked out v11 yet, but since it's not yet mentioned I assume the
admin UX hasn't been addressed. Of all the tools I have admin on, Gitlab's
admin UI (spread out across multiple sections) is perhaps the most sprawling
and confusing. For example, there are two "repository" sections in each repo
(one top level, one under settings) - in one you can perform repository admin
such as branch management, and in another you can configure things like deploy
keys. The groups/users/repo setup is another example of a clunky workflow -
functional, but too many steps, and stitched together CRUD UIs. I get the
feeling no product manager has sat down to address admin cohesively for a
number of years, but rather that it has just grown organically.

My other big wish for the product is better CI. Gitlab certainly makes Travis
unnecessary, but it doesn't scratch the surface of the functionality that
Jenkins provides via the plugin ecosystem. Yes Jenkins is janky (although can
be made to look nice enough via themes) - but Gitlab doesn't even address
parsing xunit results and displaying trends in a project centric reporting
location ([https://gitlab.com/gitlab-org/gitlab-
ce/issues/17081](https://gitlab.com/gitlab-org/gitlab-ce/issues/17081)),
instead steering you towards build centric "pages". Get the reporting built
out (and also allow it to natively consume/parse/understand output from major
testing & static analysis frameworks), and it would be a more compelling
alternative. Nobody wants to look at hundreds or thousands of lines of
build/test output - the CI tool should summarize the reasons for success or
failure.

Finally, we're having to run our self-hosted Gitlab on an absurdly large EC2
instance (8 cores, 32GBs). Occasionally we'll have a dozen people converge on
a single important PR for review, and before upgrading to our current server
this type of event would often bring our instance to its knees. Language
choice may be a significant contributor to this -- rewriting major parts of
the backend in Go or some JVM language would probably be a good product goal.

~~~
jeremy_
You're right. The UX in GitLab's admin settings has lots of room for
improvement. The good news here is that we now have a product manager devoted
to this area, and have a number of improvements scheduled here that should
help. A few I'm excited for that we're hoping to schedule for 11.2:

\- Splitting the admin settings into multiple sub-pages to make it easier to
visually parse ([https://gitlab.com/gitlab-org/gitlab-
ce/issues/44998](https://gitlab.com/gitlab-org/gitlab-ce/issues/44998))

\- Adding search for settings pages ([https://gitlab.com/gitlab-org/gitlab-
ce/issues/41112](https://gitlab.com/gitlab-org/gitlab-ce/issues/41112))

\- Prioritizing content on settings pages ([https://gitlab.com/gitlab-
org/gitlab-ce/issues/47405](https://gitlab.com/gitlab-org/gitlab-
ce/issues/47405))

The UX team has an epic on these improvements
([https://gitlab.com/groups/gitlab-
org/-/epics/203](https://gitlab.com/groups/gitlab-org/-/epics/203)), grateful
for any feedback on specific issues. Thanks for pushing us here to improve.

~~~
flavor8
Great! Thank you for the response. I'm glad to see the momentum you have.

~~~
svesselov
Thank you for the feedback! Keep it coming as we improve the admin area :)

------
a_imho
It might be interesting to someone that GitLab is not seem to be compliant
with current European data regulations (GDPR), it is worth reading their terms
and privacy statements [1][2]. E.g. even self hosted GitLab phones home in
opt-out fashion.

 _GitLab collects information about usage from each self-hosted GitLab
instance (Community Edition and Enterprise Edition) through a usage ping. The
usage ping sends a payload containing data such as total number of projects
and pipelines, as well as license information and hostname to GitLab._

...

 _The information from the usage ping is not anonymous, it is linked to the
hostname of the instance_ [3]

...

The documentation is a merge request [4]

 _This MR loads the EE usage ping asynchronously on the admin application
settings page and now includes the counts of the following items:

Comments Groups Users Projects Issues Labels CI builds Snippets Milestones
Todos Pushes Merge requests Environments Triggers Deploy keys Pages Project
Services Issue Boards CI Runners Deployments Geo Nodes LDAP Groups LDAP Keys
LDAP Users LFS objects Protected branches Releases Remote mirrors Web hooks_

[1][https://about.gitlab.com/privacy/](https://about.gitlab.com/privacy/)
[2][https://about.gitlab.com/terms/](https://about.gitlab.com/terms/)
[3][https://docs.gitlab.com/ee/user/admin_area/settings/usage_st...](https://docs.gitlab.com/ee/user/admin_area/settings/usage_statistics.html)
[4][https://gitlab.com/gitlab-org/gitlab-
ee/merge_requests/735](https://gitlab.com/gitlab-org/gitlab-
ee/merge_requests/735)

~~~
icebraining
Remember that the GDPR only applies to personal data. That is defined rather
broadly, but it still might not apply to all the information you've mentioned.

~~~
a_imho
In the EU IP alone could be considered PII, it would seem logical that
hostnames are too, but I never saw it spelled out. The counters are sent _in
combination_ with these identifiers. The summary above is compiled from
GitLabs own sources. Most probably don't care but some might.

~~~
merb
> In the EU IP alone could be considered PII

that statement is wrong. first of all IP Addresses are __only __PII if you
store them to identify users, means that if you are user table has an
ip_address field, it is, however... if you store all ip 's accessing your
service in a database to find malicious logins it isn't. so basically the
statement is, it depends. the connection of user to ip makes it PII.

~~~
a_imho
I think we agree context is important. However GitLab is collecting IPs in
combination with hostnames, not to mention the rest of the traffic that could
easily be used to fingerprint users.

------
gravypod
Is there any timeline for monorepo support? The ticket has been sitting in the
backlog and every once and a while I get an email when someone bumps it. I
with this feature got some love so service oriented architectues were more
manageable

~~~
sytse
Can you link to the issue? We're working on multiple things that might help
monorepos.

~~~
gravypod
Hey sytse. This is the issue number [0]. There's a few people at the company
I'm working at who have been pushing really hard to move away from GitLab to
GitHub. One of their main issues, from what I can tell, stem from this issue
and getting some integrated support for monorepos. I'm very glad you're
working on the features monorepos require.

Aside from monorepos there is one other small issue I have with GitLab. GitLab
is perfectly well situated to completely take over the software development
planning, warehousing, deployment, and testing. Documentation is really the
last front. If GitLab wikis were as powerful as Confluence I would be very
happy because I'd never need to use that terrible bloated site ever again.
I've been pushing for us to switch to GitLab wikis for a while but 2 coworkers
keep saying that "it is not good for long-lived out-of-project documentation,
it's not as searchable, you can't drag and drop for graphs, it's not as
integrate, and it doesn't have as many features as Confluence".

I hope one day GitLab can be my one-stop-shop for everything.

Thank you very much for making such an amazing product.

[0] - [https://gitlab.com/gitlab-org/gitlab-
ce/issues/18157](https://gitlab.com/gitlab-org/gitlab-ce/issues/18157)

~~~
sytse
Thanks for linking the issue. I'll discuss it with our product leaders.

Regarding the documentation we see many people switching to static websites
generated with GitLab pages. This allows you to separate the change from the
approval. Is this an option for you?

~~~
gravypod
Personally I think that works and gives you all of the "edit-locally" benefits
(Accessibility, hotkeys, versions, distributed/backed up etc). What that
doesn't give you is a few other important features.

My coworkers are concerned with the following:

    
    
        - Highlight and right click docs -> new ticket
        - Drag and drop flow chart creation
        - Non-developers can document and plan
        - Full text search
        - "Name spaced"/grouped documentation 
        - Third party integration

~~~
sytse
I agree that most of those are not in the wiki nor in GitLab pages.

For non developers you can make it easier to edit by linking the bottom of
each page to the reposity. See our website or docs pages for an example of
that.

------
realPubkey
When will it be possible to revert commits in non-master branches in the UI?

~~~
Vinnl
It already is? If I visit a single commit's page, in the Options drop-down on
the top right-hand side I can click Revert, and a modal pops up asking me in
which branch I want to revert that commit.

~~~
realPubkey
Yes there is that dropdown. But when you select your feature branch and click
submit, some magic happens that does not do what you think it does.

~~~
Vinnl
Hmm, what magic is that? It appears to create a new branch with the revert,
and create a merge request from that branch to the branch I select - which is
what I expected. This is of course with "Start a new merge request with these
changes" checked. When it's unchecked, I'd expect it to make the revert commit
directly on that branch; is that not what happens?

------
apazgo
linked merge requests would be my killer feature. VERY often we need to change
multiple repositories at the same time. Like for example backend+frontend
changes that's in different repositories. Having a linkage between them, that
would make them be merged together would be awesome. And also prevent merge if
one is "wip" or unresolved discussions etc...

~~~
jeremy_
We're working on this! We've wanted to explore this for some time; we're
tentatively calling this a "super" MR and putting some design time into 11.2
to understand how this might work. Lots to think through here. Love to get
your thoughts in the discussion so far: [https://gitlab.com/gitlab-org/gitlab-
ee/issues/3427](https://gitlab.com/gitlab-org/gitlab-ee/issues/3427)

~~~
apazgo
Cool stuff, way more advanced than I thought of. I don't have an account but
might create one, on phone right now. But I drop my 2 cents here. I rather see
a free version with a simple relationship between MRs. Basically;

    
    
      If linked_mr:
        print "warning, merging this will also merge:" + linked_mr
    
      ...
    
      Function merge()
        ...
        if linked_mr:
          merge(linked_mr)
    

Then building a more advanced version for EE.

------
amelius
Another attempt at centralizing our data (+). It may be a great piece of
software (or not, I don't know), but no thanks.

(+) by data I don't mean the repo itself, but all the data around it (issues,
project management stuff, etc).

~~~
louiz
What’s wrong with having the issues, project management stuff, CI, etc in one
place, as long as you control that place?

~~~
dspillett
and as long as you are not forced to is the built-ins if you prefer (or are
otherwise already committed/constrained to) something else.

------
sigzero
Still can't upload more than one file at a time using the web interface.

------
pknopf
I can never tell what the HN community thinks of GitLab.

Either the entire thread is loves it (for the most part), or the entire thread
hates it (for the most part).

 _shrugs_

~~~
skinnymuch
Can you link to a time where the majority of a thread has hated on Gitlab?
Maybe the one where they don’t pay too much and have a scale based on
location, but I might be forgetting the ratio of hating and that wasn’t a
topic relevant to Gitlab as a software project.

Otherwise it’s usually at least some or majority love for Gitlab on HN.

~~~
pknopf
I felt like this thread is way more negative than the others.

Most of the time, it is all love.

------
Walkman
If you are using the Omnibus package on Ubuntu, don't upgrade! It just broke
my instance. and can't find out what's wrong. Great features... It was a big
mistake to trust GitLab, I already predicted they will have problems.

~~~
jobvandervoort
What is the output you get? Consider creating an issue here so we can help you
debug: [https://gitlab.com/gitlab-org/omnibus-
gitlab/issues](https://gitlab.com/gitlab-org/omnibus-gitlab/issues)

~~~
Walkman
Here we go: [https://gitlab.com/gitlab-org/omnibus-
gitlab/issues/3615](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3615)

