Currently, group/project/merge_requests/new (Projects::MergeRequests::CreationsController#new) renders all branches server-side rendered for the dropdowns. This becomes a problem when a project has 20,000 branches and the DOM becomes unresponsive.
Only return the first 50 branches and add remote filtering. This is what is what we currently do for listing projects when you want to move an issue which also uses gl_dropdown.
Eric Eastwoodchanged title from Branch picker when creating an MR is slow (many branches) to Slow branch picker when creating a merge request (many branches)
changed title from Branch picker when creating an MR is slow (many branches) to Slow branch picker when creating a merge request (many branches)
Eric Eastwoodchanged title from Slow branch picker when creating a merge request (many branches) to Slow branch picker when creating a merge request (many branches) - Projects::MergeRequests::CreationsController#new
changed title from Slow branch picker when creating a merge request (many branches) to Slow branch picker when creating a merge request (many branches) - Projects::MergeRequests::CreationsController#new
@smcgivern : For the new merge request page flow, in a given project, I see that when you navigate to the new merge request page, the source branch is with respect to that project, and you cannot change it. For the target branch, you can specify a branch belonging to a project that is not the project you just came from. If you do that, and submit/create the mr, the mr belongs to the the target branch's project. (I.e. forking flows.) Just wanted to verify this is the case. (And not proposing to change anything right now.)
Let's take the goal of this issue to increase the speed of selecting the source branch and target branch in the new merge request flow, with UI being a secondary concern. Can/should we just work on the BE changes, without any FE changes? Or would it be simpler to port part of the pieces in https://gitlab.com/gitlab-org/gitlab-ce/compare?
Ideas of current workarounds, depending on your use case:
At GitLab, we encourage people to create a merge request immediately after they create a branch, so as to promote collaboration right away. So that means if even your branch has no changes yet, just having the merge request already created is a flow that we support. So even if you don't want/need that collaboration immediately, but you have no problem with creating a blank merge request right away when you create the branch, some of these might be helpful workarounds.
When you create a branch in GitLab, in the UI, there is a helpful button, while you are in the repository navigation or merge requests navigation, to create a merge request right away. Just click the button and it bypasses the slow page described in this issue, because GitLab already chooses the newly created branch for you. (You end up on the new merge request page right away with the branch pre-selected.)
In another flow, if you are using GitLab issues, you can create a branch and the associated merge request right away from the issue page itself.
So even if you were not using GitLab issues, and really just wanted a quick way to create branches and associated merge requests, you could use this method to create dummy issues to do so. Obviously not elegant. But a workaround nonetheless.
Finally, you can create a merge request through the API. This is a CLI (https://github.com/narkoz/gitlab) that says it wraps the GitLab API. I just found it by looking at this open issue (https://gitlab.com/gitlab-org/gitlab-ce/issues/13329). Note that this is not an officially supported GitLab CLI or flow. But just wanted to mention it here as a potential workaround.
@victorwu you're right that there is a project selector, but you cannot select branches from different projects. So we could use the same idea as the dropdown on the compare page, for the project you selected in the first drop-down.
@victorwu anything that doesn't try to load all the branches on page load would work. The compare page returns at most 100 branches (filtered by the user's input) and 100 tags (likewise).
@winh why does it need to take forks into account? Wouldn't you just use a different refs endpoint depending on the project selected in the other dropdown - so the backend would provide the path for getting refs for each project in the dropdown.
I'll let you and @mdelaossa figure out the details, though.
@victorwu Can we commit to a release date? This blocks customers from using GitLab for repositories with a big history of tens of thousands open branches.
@jramsay I just realized that protected branches / tags dropdowns in project repository settings suffer from the same problem as this issue. Are you aware of any issue to target them?