Bug? Creating merge request on gitlab.com changes the target branch to master

Expected behavior: Load the “merge_request/new” page, select source branch “source_branch” and target branch “target_branch”. Click “Compare branches and continue”. The next page shows “Title”, “Description”, “Assignees”, “Reviewers”, etc. Above title it should show “From source_branch into target_branch [Change Branches]”.

Observed behavior: The 2nd page rather than showing “From source_branch into target_branch [Change Branches]” it shows “From source_branch into master [Change Branches]”.

This has happened to me at least ten times since last Friday the April 15, 2021 and never before that. This happens on multiple repositories. I can click “Change branches” to fix this and it still goes back to “master”. This apparently incorrect behavior does not happen 100% of the time, more like 70% of the time.

See the illustration in the attached screenshot.

Has anyone else seen this? And is this a bug or am I missing something silly?


I see the similar behaviour, in fact, it is now impossible to create MR for our project from forks (people need to attach patch manually.) If you create merge request from fork, it switchws to default branch on the fork itself.

I can reproduce it for cryptsetup / cryptsetup · GitLab but not for another project under the same group. We recently changed default branch from master to main, but seems it is not related here.

To me this looks like quite serious bug making GitLab workflow practically unusable for some contributors.

This is perhaps tracked here Fork relationship is not respected for certain projects (#358665) · Issues · GitLab.org / GitLab · GitLab

Seems it is better to report issue than ask on a forum nobody reads :slight_smile:

1 Like

Thanks for finding and linking the issue. For things which seem off, or look like a bug, breaking behaviour, or otherwise impacting workflows, I’d recommend raising an issue so that awareness is increased.

You can tag me here if urgent. At the moment, I’m too busy to engage here often - I will be speaking at KubeCon EU in 3 weeks, exciting and busy times :hugs:

Devs don’t read forums, they read the issues opened on the project, which are assigned categories like bug or whatever. So that would be the place you need to open for it to get addressed (of which you did anyway). Reporting a bug on a forum won’t get it resolved. Which is understandable, from a dev point of view it’s far easier to follow and track everything from one location than have to check multiple sources.

From the forum, you can expect help for problems, eg configuration issues, upgrade issues, that kind of thing. Although as with everything, free support is limited, and not all problems get a response. But that could be because nobody experienced the problem or don’t know how to fix it. That’s not unique to the Gitlab forums, but rather any forum in general can have that situation. That’s just the way it is.

HI Ian, I perfectly understand that. But we have license under OpenSource program that obviously do not include support and the first step described here Support is to open a thread on the forum, not to fill an issue. But in the case of sev2 issue like this one it is counterproductive…

Anyway, thanks for your response,
Milan

Yeah gitlab could communicate that better eg support then forum else bugs open issue. Would save confusion.

I think there is a misunderstanding between support tickets and issues, trying to clarify.

Customers can open a support ticket, which is a different platform and has support teams to respond and help with priority.

The Open Source program doesn’t come with this support option, thus asking you to kindly open a topic on the forum to ask for help. This is generic advice covering most cases for when support questions come up (installation, usage of specific features, problems with workflows, etc.).

Though, if you see a bug or anything breaking the product and platform, everyone is encouraged to create issues to report and discuss the problems. In this specific case, the merge/fork relation was affected and functionality deployed onto GitLab SaaS did not work. GitLab SaaS is a rolling release continuously deploying GitLab - self-managed users get monthly releases on the 22nd. Reporting the problem early allows to develop a fix, deploy to GitLab SaaS and self-managed releases do not get to see the problem in the best case.

The same suggestion applies to missing features or ideas to propose - everyone can contribute, with an issue and/or merge request. :slight_smile:

Tip: If you are unsure about it being a bug, a discussion within the community can help identify the problems and invite further actions, e.g. by opening an issue, or searching the issue tracker together. A well-thought discussion, and research with things tried out, and then linked in an issue is very much appreciated by GitLab team members and wider community contributors. :slight_smile:

1 Like

Thanks, actually I was just preparing info for reporting a new issue - and found that the linked one is already escalated to sev2 (for some reason I did not find it a day ago).
But it would be nice if GitLab mentions this on Open Source program - I understand no support ticket option, but if the problem is serious, it should encourage users to fill an issue directly - just as you said here.

Thanks for the info.

Thanks, I have created a new issue in the OSS program tracker to clarify and review the process. Clarify on support options for OSS programs and how to report production incidents (#264) · Issues · GitLab.com / marketing / Community Relations / Open Source Program / general · GitLab

My firm pays real money for support, next time I’m just going straight to support. I thought I was being a good boy by filing it in the community forum first but next time …

Thanks for reporting here for everyone to see and contribute. It is also possible to create a forum topic, and link it in a support ticket or issue to raise awareness.