Change target branch when creating a Merge Request

Problem to solve

My team works on a product where we support two or more major versions at the same time. So in GitLab we have multiple "main" branches. When someone works on a new feature or bugfix, sometimes they are targeting trunk/7.1 and sometimes trunk/7.2. GitLab prefers to direct us to whichever one is the default, so when we target the other one we need to do extra steps to change the target branch.

Doing the extra steps is a minor hassle, but a more serious issue is that if the developer doesn't notice the wrong target branch then there are other issues downstream: The "Diff" page for the MR is not accurate and can lead to confusion, and a merge of that MR to the wrong branch could bring lots of unwanted changes.

Changing GitLab to support multiple "default" branches is probably a major project. But there might be a little change to the GitLab Workflow VSCode extension that could help.

Proposal

image

When I click on "Create MR" in VSCode, it sends me to a URL like .../-/merge_requests/new?merge_request%5Bsource_branch%5D=my-branch. On that page, if I click "Change branches", it sends me to .../-/merge_requests/new?change_branches=true&merge_request%5Bsource_branch%5D=my-branch&merge_request%5Bsource_project_id%5D=248&merge_request%5Btarget_branch%5D=trunk%2F7.1&merge_request%5Btarget_project_id%5D=248.

If it were possible to change some setting in the extension to send us directly to the change_branches=true version of the URL, it would save us a step and help to avoid badly-made MRs. Developers would then be asked right away which branch they want to target.

I'm imagining a new boolean configuration option in the extension. If set, it would just change the URL that the "Create MR" button goes to.

That option would also affect the gl.openCreateNewMR command.

Other options

I could also imagine a change where VSCode itself asks what the target branch should be, but that sounds like more effort and the change_branches page in GitLab itself is sufficient for my purposes.

Edited by James Clark