Skip to content

Creating new MR from non-default branch is buggy

Summary

Creating MR's from an issue using the blue drop-down button produces (seemingly) non-deterministic results. Sometimes using the wrong source branch, sometimes including old commits from the source branch and giving them new hashes, creating initial conflicts upon creation. Sometimes the branch cannot be created at all, giving the error message "

Steps to reproduce

Use the drop-down menu within an issue to create a new MR and feature branch. Anything other than the defaults will cause non-deterministic errors.

Example Project

I don't have time to do this..

What is the current bug behavior?

We've experienced buggy and erroneous behavior from GitLab when creating new feature branches the last couple of (1-2) weeks. Our normal work flow is to create an issue and create a MR from within that issue. This has worked flawlessly the last year, until a few weeks ago. Firstly, when closing merging and closing the MR, the issue isn't always automatically closed. This is a minor thing that's been a small annoyance for a month or two. Secondly, the big issue we ran in to recently is when creating a new MR and branch, the branch includes multiple old commits, making it conflict with the branch it just was created from. We had lots of issues squashing and merging our changes because of the initial duplicate commits that was added when first creating the MR and feature branch.

I'm not sure, but it seems this issue happens when creating a feature-branch from a non-default branch. We usually develop against a branch called develop, but now we're doing a major rework, and thus have created a feature branch that's basically a develop2-branch. The workflow that gives us trouble now is:

  1. Create an issue.
  2. Create a MR 2.1 Change source branch from default develop to develop2

If we do this multiple times, the outcome is non-deterministic. Sometimes it all works out, and we get a new, clean branch based on develop2 with no initial extra commits visible. Sometimes we get a new branched based on develop2 as we intend, but with multiple (10-20) differing commits, seemingly copied from the source branch (develop2) and given new hashes. And sometimes we get a new feature branch not even based on develop2, but instead based on the default develop-branch, even if we make sure it's created based on develop2 in the gitlab web gui.

What is the expected correct behavior?

Creating a new MR and branch from the drop-down menu in an issue (path https://gitlab.com/my_company/my_project/-/issues/871) should create a new MR and an associated branch based on any source branch selected (and given a "green light" by the GUI), including no conflicting commits.

Relevant logs and/or screenshots

Creating a new MR and branch from a non-default branch. image

Creating a new MR and branch with a custom name. Note the 22 added commits that shouldn't be there.
image

(For installations with omnibus-gitlab package run and paste the output of: sudo gitlab-rake gitlab:env:info)