jramsay

> it's unusable for large changes and large files. On large changes it sometimes won't even show all the changes.

Improving the performance and scalability of merge requests is the priority for the Source Code team right now, and we are starting with progressively loading the diffs over coming releases. See https://gitlab.com/groups/gitlab-org/-/epics/1816. Currently we load them in a single request which is a serious bottleneck.

In parallel we are exploring a range of UX changes to streamline and improve the code review experience. If you have any specific ideas please let us know, or create an issue!

> Also, merge trains for FF-only repos, please!

Absolutely! We are iterating towards this https://gitlab.com/gitlab-org/gitlab-ce/issues/58226!

amasad, I enjoyed the perspective of your article. I agree an engineer with many years of experience is going to have different expectations to someone who is entering the profession today. I think it's similar to my perspective on the iPad – I find it interesting but limited because my experience and mental model of computing is very different to someone who is growing up with an iPad in hand.

I work on the Web IDE at GitLab (among other things) which we built after we noticed that there were a few situations in our day to day work on GitLab where we didn't need a full local development environment, like updating documentation or addressing simple review comments. It doesn't replace a local IDE from me yet, but it is helpful and we hope we can make it more useful in more situations where local IDEs have shortcomings. I think the effort and maintenance of a local development environment is also a cost that is frequently overlooked – reinstalling dependencies is a headache that disappears in an automated ephemeral environment like repl.it or where we're heading at GitLab.

But that seems like it's just an iteration on the status quo rather than leap frogging to a post-IDE world. I think the idea of online interactive development can go so much further. Maybe we can integrate interactive editors/terminals/previews with our planning and code review tools so that experimentation and exploration are easier and happen in line in the discussions we have planning the next feature to build. I put a few dot points down on this line of thinking last week https://gitlab.com/groups/gitlab-org/-/epics/533 but I'd be interested to hear some of your more concrete ideas of what a post-IDE world might look like.

Amazing! Here's an issue we can use to discuss: https://gitlab.com/gitlab-org/gitlab-ce/issues/41925

Thanks for the feedback. I’m a Product Manager for Create (Git, merge requests etc) at GitLab. Why do you think the repository part of the project isn’t clear enough? What would make GitLab’s repo capabilities less diluted for you? I want to make sure using Git with GitLab is great.

Thanks for taking the time to share your feedback. I'm the Product Manager responsible for merge requests. Approvals are such an important part of merge requests, and we are working to make them better.

We've improved a number of confusing approval widget states in GitLab 11.2 (https://gitlab.com/gitlab-org/gitlab-ee/issues/5439) which will ship later this month in and the ability to filter merge requests by approver is in development by a community member (https://gitlab.com/gitlab-org/gitlab-ee/issues/1951).

This is just the beginning though – code reviews and approvals are at the heart of the daily workflows of writing software and we'll be continuing to make them even better. I'm particularly excited about more structured code reviews with batch comments in 11.3 (https://gitlab.com/gitlab-org/gitlab-ee/issues/1984), better navigation between files in merge request diffs with a file tree in 11.4 (https://gitlab.com/gitlab-org/gitlab-ce/issues/14249), and our first iteration of code owners (https://gitlab.com/gitlab-org/gitlab-ee/issues/5382) also in 11.4.

Thanks for the disapprove merge request idea. We're considering this idea in https://gitlab.com/gitlab-org/gitlab-ee/issues/761 where further feedback would be much appreciated, or on any other issue.

James (Product Manager at GitLab) here. I've just picked up merge requests and have seen lots of feedback across multiple issues related to navigating between diffs/files when reviewing a merge request, and I want to make it better too.

There have been a few different solutions proposed including adding a file tree to the merge request interface, so you can quickly see a full list of the files and how they relate to each other. There is a design discovery issue for adding a file tree to the merge request interface https://gitlab.com/gitlab-org/gitlab-ce/issues/49189 scheduled for the next release to work out the UX in more detail.

Would a file tree make reviewing a merge request easier for you? Thanks for the feedback, and would love to hear more here, or on the issue.

Thanks Daniel. I'm a Product Manger at GitLab. The relative submodule fix is scheduled as a Deliverable for 11.3 https://gitlab.com/gitlab-org/gitlab-ce/issues/25535 – sorry it's taken so long.

Normally new duplicate issues are consolidated into the oldest issue, but since both issues had been open a while ago I kept the issue that had the most participants and discussion open.

Hi Spidler, I'm a Product Manager at GitLab. Thanks for the feedback. Solid security protecting deployment is very important.

In GitLab 10.7 we added branch unprotecting restrictions that can be managed through the API to restrict who can modify protected branch rules https://docs.gitlab.com/ee/api/protected_branches.html#prote..., and we'll be adding a UI to manage this soon too. I created https://gitlab.com/gitlab-org/gitlab-ce/issues/49513 to add an auth step for changing protected branches as well.

I'm interested to know more about the version number improvement you suggest too. There are a few similar proposals like automated tagging on merge https://gitlab.com/gitlab-org/gitlab-ce/issues/22363.

Thanks for your feedback. I've just taken on merge requests as part of my responsibilities, and hope to schedule this soon!

Here's a link to the issue: https://gitlab.com/gitlab-org/gitlab-ee/issues/1951

I'll