DouweM

GitLab backend lead here, and the guy who developed that feature :)

What you're describing is indeed a departure from previous behavior, but I think it is a change for the better, even if it may take a little bit of getting used to. You're not the only one who was surprised by it though, and it's being discussed in https://gitlab.com/gitlab-org/gitlab-ce/issues/21406 I've laid out my thoughts in a comment there.

Feel free to chime in; as always, we'd love to hear your input!

If you copy-paste the URL for a specific comment into a new comment it will show as `#123 (comment 234)` and link to that comment. There is no special reference syntax to link to a specific comment, because it's much more likely that you have the URL to a comment on hand, than just its ID :)

Mattermost is not enabled on GitLab.com, in part because it's not prepared for multi-tenancy, and in part because it is shipped with the GitLab package specifically for people who want to have a self-hosted development and collaboration environment. If you're fine with using hosted tools, there are plenty of great hosted chat tools out there!

Depending how small the fix is, you can edit a file in any project right from the GitLab interface, and a fork and merge request will be created automatically in the background! The only thing left to do is to remove the fork after the MR has been accepted.

We compare GitLab with a bunch of other tools on our website: https://about.gitlab.com/comparison/. We don't have a section on Phabricator yet, but if you end up trying both GitLab and Phrabicator, please consider writing down some of your observations!

Like all of our website (and our product, as a matter of fact), we accept merge requests to improve that page: https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/sou...

GitLab can actually keep your GitLab and GitHub repos in sync automatically! Check out the "Mirror Repository > Push to a remote repository" option in your project's settings.

CE does support restricting branches to specific roles: Master and Developer. In your case, I would suggest giving this single maintainer the Master role (which they already have if they're the owner of the project), making everyone else a Developer and configuring the master branch to only allow pushes (and merges) from Masters.

Both of those formats also work in comments outside of slash commands, are automatically linked to the respective entity, and label references are rendered as pretty labels, with their color and description tooltip.

Using those characters also enables autocomplete in the Markdown textarea.

In the web interface, they are very convenient, but they are not required, so when using slash commands with reply-by-email, you can leave them out and write exactly what you have under "Instead of"

I added the blockquote fence feature because I was getting tired of having to manually prefix every line with `>` when I was quoting a multiline message like an entire email.

I picked `>>>` because it mirrored the triple-backtick syntax for fenced code blocks, and `>` was already used for single-line blockquotes.

You can see the feature proposal I filed at https://gitlab.com/gitlab-org/gitlab-ce/issues/16564, and the merge request I submitted to implement the feature at https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3954, for some more insight into how this came to be.

I'm sad to hear that this feels like reinventing the wheel to you. From my perspective, there existed an imperfect wheel that we "invented" a more powerful alternative to.

Yep, you're right, our Markdown documentation describes a lot of GitLab Flavored Markdown that will (currently) only work inside GitLab itself, not on the docs site which uses a completely different Markdown renderer.

I've added a note to the top of the document encouraging people to view it within GitLab: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5440

You can check out the Videos example in all its glory here: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/mark...

It appears however that it doesn't currently work correctly with files in the same repo, just with absolute links. I've created an issue for that here: https://gitlab.com/gitlab-org/gitlab-ce/issues/20189

Good catch! Our Markdown documentation describes a lot of GitLab Flavored Markdown that will (currently) only work inside GitLab itself, not on the docs site which uses a completely different Markdown renderer.

I've created a Merge Request to add a note to the top of the document encouraging people to view it within GitLab: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5440

You can check out the Multiline Blockquote example in all its glory here: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/mark...

Hi Jacques, I would appreciate some more context as well!

It's not a coincidence! I study Computer Science at Utrecht University and work at GitLab, so https://git.science.uu.nl only made sense :)

A little bit of stalking shows me we're actually in a class together, see you on Monday ;)

Downgrading from EE to CE is officially supported. You can find the docs here: http://doc.gitlab.com/ee/downgrade_ee_to_ce/README.html

Because Matt is too nice to plug his own app, I will do it for him. Check out Trident: http://www.somerobots.com/trident.html It's a really nice app and we are happy to make improvements on our side to make it even more capable with every release :)

I edited my comment to point out that the same is the case with GitLab.com. (I should've been more specific)

GitLab.com is completely free, and has both unlimited private repositories and unlimited collaborators!

The GitLab EE source is publicly viewable, but its license is not open source. See https://about.gitlab.com/2015/05/22/gitlab-7-11-released/.

All right, I see where you're coming from. I think any eventual GitLab acquirer would be mad to screw up _our_ winning open core formula, but I'm not in a position to tell the future or make any promises.

I've asked our CEO Sid (you know, the "GitLab CEO here" guy) to chime in.

Hmm, the front page (https://about.gitlab.com/) lists "GitLab.com — On Our Server — Free hosting for private repos? Sign up to get unlimited repos and collaborators. — Sign Up", but I get that it's a bit confusing that the features and pricing pages don't mention anything about it.

To clear things up: GitLab.com is completely free, with unlimited projects and collaborators. GitLab CE is open source and completely free. GitLab EE costs money and has a 45-day trial.

> 1. My hosting is way more reliable than yours :-)

You've got me there :) I'm sure your aware of our intention to greatly improve GitLab.com reliability and performance in Q1 2016: https://gitlab.com/gitlab-com/operations/issues

> 4. My repository mirroring is quite a lot better than yours, as it's instant, not hourly

Heh, care to share? :) Maybe we can take some pointers from your implementation. How does your repository mirroring know that the upstream repo was updated? Do you use webhooks on GitHub? That would actually be pretty easy to implement, an `update_mirror` GitLab API endpoint that GitHub could call to, hmm...

> 5. I prefer to have a commercial relationship with important tools. You seem like nice people, let's see what happens when you get acquired.

What are you afraid of?

> As long as you can't be bothered to sell to 2-person teams, I'll just run CE and have my commercial relationship with AWS instead.

Fair enough!

> I run an open source GitHub organization and wanted to use GitLab as CI. It works! But I needed to reimplement an EE feature to do it.

Is there a reason why you didn't use GitLab.com, which runs EE and thus has Repository Mirroring?

> I'm just saying that the EE features are not all "mostly interesting to companies with 100+ employees." Several of them are things I needed as a single open-source developer.

Fair enough, I'm not saying our judgment of what is and what isn't interesting to smaller/single-person teams is perfect. If the general feedback of the community is that a certain piece of functionality belongs in CE rather than EE, we will consider bringing it to CE. We have done this in the past.

> A hobbyist should not need to host their own repo, they should be able to rely on their SaaS. I would love it if GitLab.com could be rock stable like GitHub

Believe me, we would too and we are sorry about the current state of GitLab.com. We are working on improving performance in Q1 2016: https://gitlab.com/gitlab-com/operations/issues

GitLab CE is not crippled in any way, it is used every single day by hundreds of thousands of companies and millions upon millions of developers. It is and has always been our (GitLab, the company) main focus, we only decide to make new features EE-only when we think that they are mostly interesting to companies with 100+ employees. Besides the company's efforts, contributions from the 1000+ community contributors always go into CE, unless the contributor submits it to the EE repository specifically.

As evidence, just look at our Direction page: https://about.gitlab.com/direction/, or compare the CE and EE changelogs: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELO... vs https://gitlab.com/gitlab-org/gitlab-ee/blob/master/CHANGELO....

Note that our free, hosted GitLab.com runs EE, which means that EE features like GitLab Pages ("Hosting static pages straight from GitLab") are available to everyone.

GitLab Community Edition is fully open source and completely free: https://about.gitlab.com/features/#community

Which is almost exactly what happens on GitLab: https://twitter.com/gitlab/status/687930087057027073

Users can use those buttons to +1 or -1, and any comments that contain nothing but an emoji (like `:+1:`) are automatically converted to emoji awards, as we call them.

I’ve handled your application. I’m sorry you felt that you were not treated well during your application to GitLab. We set a very high level for our developers and do our best to maintain this. We try to communicate clearly to our applicants on what grounds we refuse their application. How would you prefer this to be handled instead?

Hi nadams, I just replied to your original post, at the same time you posted this one. If you have any questions that aren't answered in that reply, feel free to ask!

GitLab developer here! Thank you, Sytse, for answering already, I'm happy to go into a little more depth.

> I highly recommend showing users the key for their storage - I've had to extract the keys from FreeOTP and Google Authenticator a number of times.

I'm curious, in what situation would you need to extract the key while you still have access to it in one of your apps? We have recovery codes for the situation where you've lost the key in your app, but that doesn't seem to be what you're describing. If you're moving from one app or phone to another, you can just turn off 2FA on GitLab and then turn it on again—you'll get a new key.

> How do you leverage 2FA with LDAP/AD accounts? Do you store/check the key in gitlab and then auth the users against LDAP/AD - or store the key in LDAP/AD?

The 2FA flow is the same for regular GitLab users and those backed by LDAP. After the initial username/password auth step, they are presented with the 2FA form. In both cases, the key is only in GitLab.

GitLab developer here; it does! Where GitHub only allows images to be dragged into issue and comment description fields, GitLab allows this for any type of file.