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...
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.
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.
See https://about.gitlab.com/contributing/ and https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU...
https://gitlab.com/gitlab-org/gitlab-ce/blame/57ce7c655cc58e...
Did you have some particular feature request beyond this view?
This has been available on GitHub for a while now (see https://help.github.com/articles/tracing-changes-in-a-file/)
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.
> 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).
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.
How many steps was that?