When resolving conflicts within a merge request through Gitlab, the changes are not automatically updated on branch

Summary

When I go to resolve merge conflicts within a merge request on Gitlab, whenever I resolve the conflicts through the application - the changes are not automatically updated / pushed to the branch / merge request, which leaves the merge request in a state where it is still treated as having merge conflicts. Please see this Loom video for a demonstration: https://www.loom.com/share/4e954383cb534c109740ef56d31b63a3.

I would expect that after I have resolved the merge conflict changes, the branch / marge request is then updated and then I can successfully merge the request. But you can see through the video that this is not the case.

Possible fixes

See comments:

• #326178 (comment 550549177)
• #326178 (comment 550630927)

mentioned in issue gitlab-org/quality/triage-reports#2459 (closed)

Reproduced in GitLab.com:

• caalberts/gitlab-sandbox!29 (diffs) # This MR was merged, creating conflict in the next MR
• caalberts/gitlab-sandbox!30 (diffs) # This MR still shows conflict even after resolving it.

@danielgruesso @sean_carroll

caalberts/gitlab-sandbox!29 (diffs) is merged, with the following diff:

- # ci-sandbox
+ # ci-sandbox-1

This creates conflict in caalberts/gitlab-sandbox!30 (diffs). After resolving the conflict in the UI, the diff still shows

- # ci-sandbox
+ # ci-sandbox-2

instead of

- # ci-sandbox-1
+ # ci-sandbox-2

added Category:Source Code Management devopscreate groupsource code severity2 typebug labels

changed the description

Thanks for reporting this @ZaneKeeley

added priority2 label

added sectiondev label

I can confirm the issue. For now the workaround is closing and reopened the merge request, this will update the merge state.

Thanks

Premium customer here https://gitlab.my.salesforce.com/0064M00000XYT8k

Experiencing the same issue, very annoying. Thanks for taking care.

added customer label

A Bronze customer reported this in Zendesk ticket.

@m.gissing @GonzaloA

A workaround for me when I was testing this:

1. After unsuccessfully resolving conflicts in the UI I pulled down the source branch into a local git repo and it fetched the "Merge branch 'master' into 'new_branch3' commit.
2. Then I made another commit with changes in a random test file and pushed to the source branch again.

This updated the Commits tab of the MR and the MR got unblocked and I could delete the unnecessary test file and merge.

You can check this MR as an example: https://gitlab.com/gitlab-gold/kategrechishkinatestgroup/201996/-/merge_requests/3

mentioned in issue gitlab-org/quality/triage-reports#2569 (closed)

added Category:Code Review Workflow groupcode review labels and removed groupsource code label

removed Category:Source Code Management label

This is interesting because I'm not sure where this logic actually behaved as intended. Maybe before we began storing diffs in the database a long time ago.

It seems like we would want to merge_request.reload_diff and merge_request.mark_as_unchecked around here. I have tested that this solution does work. Interestingly, this is already what the E2E test is doing, otherwise it probably would've been failing in order to alert us sooner.

Correct me if I'm wrong @tomi, but wouldn't an E2E test that is calling backend actions like that automatically be invalid?

Correct @m_gill. To be precise, this is not an E2E test (they are inside qa/qa/spec/feature/browser_ui and the ee equivalent). This I believe would be a feature test (which would count closer to unit tests) but sadly I have not gotten to go through those for now as they are mostly developed by the dev's themselves or are very old (as far as I can see the test and that specific line are 4 years old).

But your assumption is correct. E2E tests and features tests as well should not circumvent buggy behavior but create an issue for it to be fixed (and marking them as workarounds if the bug is not going to be fixed soon). E2E tests, even more, should be mimicking user actions (after setup) and not depend on some function call or special trick.

One additional note in terms of the test itself (oops, I didn't even look at the directory it was in) - we really shouldn't be testing that a successful message appears, but rather that the MR is now mergeable and the commit itself was applied.

@m_gill I know it's been a couple weeks, but would you be able to update the proposal section of this issue so that whoever picks it up in %14.0 doesn't need to dig in here?

added workflowready for development label

set weight to 1

changed milestone to %13.12

added backend label

added [deprecated] Accepting merge requests label

mentioned in issue create-stage#12822 (closed)

changed milestone to %14.0

@mnohr and @phikai,

This groupcode review bug has at most 25% of the SLO duration remaining and is ~"approaching-SLO" breach. Please consider taking action before this becomes a ~"missed-SLO" in 14 days (2021-05-28).

added SLONear Miss label

changed the description

added Deliverable label

removed Deliverable label

added Stretch label

A Silver Customer reported this in this internal ticket

changed milestone to %14.1

This was not scheduled in %14.0 due to capacity constraints. Adding to the %14.1 planning issue

CC @sarahwaldner

added SLOMissed label

changed the description

Self-hosted Premium customer here, we're experiencing the same issue.

A MR showed "There are merge conflicts":

These conflicts were then resolved via "Resolve conflicts" in the UI, which made the "Resolve conflicts" button disappear, but not the "There are merge conflicts" message:

It appears that the merge was in fact executed on the remote branch (so the merge commit can be retrieved with git pull), but the merge commit does not appear in the "Commits" tab.

This is very frustrating for our new engineers that get used to resolving merge conflicts.

edit: The workaround by @GonzaloA only worked partially. The "There are merge conflicts" message is gone, but the pipeline status cannot be loaded (because a pipeline wasn't triggered as a consequence), which blocks the merging:

edit 2: The additional workaround we needed was to trigger the pipeline for the corresponding branch manually via "CI/CD" > "Pipelines"...

@marc_shaw Do you think this issue is related to #18917 (comment 601762154)?

@phikai This looks to be the same issue as described in the other issue

marked this issue as a duplicate of #18917 (closed)

closed

marked this issue as related to #18917 (closed)

mentioned in issue create-stage#12887 (closed)