These are exactly the type of features we are focused on this year.

Commenting on a block of code: https://gitlab.com/gitlab-org/gitlab-ce/issues/4143

Making a review session: https://gitlab.com/groups/gitlab-org/-/epics/23

And here’s a greater overview: https://about.gitlab.com/direction/#merge-requests-approvals...

Now if you guys would get to...

1. ... allow to specify somehow a size of TAB symbol per user or per project (or per review), so we might be able to review Go code normally, without plugins or custom CSS for the browser (8 char default is making code a lot harder to review,especially side-by-side). Yes, there were at least 3 different tickets opened about it the last time I have checked. No, the answer "we going to have .editorconfig support one day" or "good suggestion, maybe one day" are not making it after 2+ years, sorry)

2. ... filename not being hidden by icons would be so awesome in knowing which Java file with 200 char filepath I am trying to review without copying filename to clipboard, and looking at it in VS Code. Wrapping icons is ok, I don't care where is "copy file name" button is located that much.

3. ... have some file patterns rules about what files I would like to have collapsed by default. And while we are at it, add what files to display with ignore-space diff, and which do not, so I will not start every review with the same magic mouse triple click with full reloads of 15 files in between.

Sorry for the rant, code reviews is one of my main responsibilities and this just drives me nuts every day.

It's open source. I'm sure they wouldn't turn down a PR if you submitted one. I've poked around the codebase a few times; it's not too hard to contribute, despite my lack of experience with ruby.

Product manager at GitLab here. We welcome contributions!

See https://about.gitlab.com/contributing/ and https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU...

It's open core, not open source. I'm pretty sure they would have a lot of incentives to turn it down.

We don't have a lot of incentives to turn down contributions. Quite the opposite.

We not only encourage this, we actively help people contributing to GitLab. It's humbling to be a steward to an open source project and something we don't take lightly [0].

And to be blunt, for an organisation as ours, with very ambitious goals, and highly demanding users, having someone else than us contribute something that makes the product better is the best possible deal we could do. We can compensate for the 'lost' value in our enterprise product by spending that time on other things that are maybe more interesting for our paying customers.

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

That's reassuring, thanks for replying. I was commenting from a general perspective on open core licensing but I understand not all companies are created equal.

Here's an example of a blame on a previous commit of a file.

https://gitlab.com/gitlab-org/gitlab-ce/blame/57ce7c655cc58e...

Did you have some particular feature request beyond this view?

The use case is to be able to repeatedly blame on the previous revision of the change that was made to a line. This is especially useful when you're dealing with diffs resulted from code formatting, whitespace changes, etc. in a file and you want to see what is the "original" commit that the change was made.

This has been available on GitHub for a while now (see https://help.github.com/articles/tracing-changes-in-a-file/)

Thank you for the explanation. I've created an issue. Feel free to continue the discussion there.

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

Does this mean that gitlab doesn't generally employ people to simply learn their competitors products, to keep informed of their offerings?

This is a highly unfair criticism, you’re never going to have total feature parity with your competitors, nor is that even a good thing to strive for.

Mine is a perfectly valid criticism. You do nobody any favors by conflating the goal of total feature parity with the general concept of business intelligence, and understanding your direct competitor's key features.

The strawman you float is the complete opposite of what I asked. It simply occurred to me as strange that there are features that meet all of the following requirements:

1. Available on github for quite sometime

2. Long enough in fact to get a dedicated article in their knowledgebase

3. A popular enough feature to possibly gate the entire calculus for users to switch services.

4. Obviously useful feature, as evidenced by the gitlab triage engineer being convinced to add an issue with a single paragraph plea.

5. Gitlab is seemingly unaware of this publicly available information, to the trivially rectified detriment of their own bottom line.

You seem pretty worked up about this one feature.

> 3. A popular enough feature to possibly gate the entire calculus for users to switch services.

I'd say GitLab's CI/CD system is a lot more useful of a feature. At the very least you can use the actual git blame or another git UI as a workaround. Good luck setting up a replacement CI/CD system.

> 4. Obviously useful feature, as evidenced by the gitlab triage engineer being convinced to add an issue with a single paragraph plea.

That's not how triage works. Just because a bug is filed doesn't mean it's "obviously useful". If the employee had immediately given it a high importance, a release date, and assigned it to somebody, that'd be a different story.

> 5. Gitlab is seemingly unaware of this publicly available information, to the trivially rectified detriment of their own bottom line.

Well, since there is another bug already filed for this feature more than six months ago, [0] I'd say they are quite aware, they just don't consider it as important as you do. The particular person that replied to you just didn't know about it (not surprising when they have more than 10k bugs open).

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

You seem to baselessly project negative emotions and motivations on to your interlocutors in lieu of coherent points that actually refute their arguments.

chinhodado, the GP, framed his feature request as one of the major reasons he is forced to continue using github. Gitlab's motivation for the very feature this thread is regarding, is to poach github customers, or at the very least, increase their customer base by giving people a smoother onramp to transition from github. More power to them.

The feature he describes does, in fact, have obvious utility, which is why it was so strange to me, someone who only uses gitlab for its most basic features, to see the exchange with the gitlab engineer. Surely a company with the venture capital that gitlab has raised would perform the basic ongoing market research that any company in nearly any competitive market performs.

It honestly made me wonder if gitlab on one hand, realizes that they need to inform themselves of useful features, but for whatever reason, doesn't avail themselves of github's features.

At least you can blame previous revisions of a file? Using an URL like gitlab.com/username/project/blame/COMMITHASH_OR_TAG/path/to/file

You can, but you need to copy-paste the hash to the URL manually, which is not exactly good UX.

No you don't? If you click on a particular commit, you can click "View file @ HASH" and from the click the Blame button?

When you click on a particular commit, you see all the files affected by that commit, which can be in the dozens. Now you have to search for the file you're interested in again, click on View file at..., then in there search again for the line you're interested in, click on it then go back to the top of the page and click on Blame (or click Blame first and search for your line later, same thing).

How many steps was that?

This release is mainly for improved CI/CD and Kubernetes support. How is that related to project management?

Or basic modern web UX. Like using a wide screen effectively.

Under your profile settings/preferences, you have the ability to set your layout to 'fluid' This will allow the application to take up 100% of the width of the screen. If you have more specific UX issues you think we should address, I'd love to hear them!