MR suggestions always get applied to branch tip
Dear GitLab gurus. We observed the following behavior just recently. I have tested this separately in a private repo as well. Can anyone confirm this? Is this a known issue? Is there a solution? Thanks!
Say you have created a branch
feature-wip and a MR into
When you, being on the GitLab diff discussion page of the MR
- edit a file in that branch interactively
- apply a code suggestion
then a commit will be created in
feature-wip, with a commit message such as
Apply suggestion to <filename>
The problem: the commit will always be made on top of the branch's tip, i.e.
the most recent commit, and not the commit at which the diff discussion
started. This is no problem, unless someone (or you) pushes new commits to
feature-wip, moving tip forward. Now all not yet applied code suggestions refer to
an older version of the file, but will be applied onto the new tip, which may
lead to merge conflicts.
In the particular case above, we even saw a GitLab message saying something like "this ... referes to an older version of this file ...", with links to the versions and everything.
To make things more visual, this is what happens:
* aab4893 (HEAD -> feature-wip, origin/feature-wip) Apply suggestion to foo (GitLab GUI) | * b02d02f Pushed | * 3edc93f Apply suggestion to foo (GitLab GUI) | * f9c2a59 Apply suggestion to foo (GitLab GUI) | * 034b71f WIP: foo | ... | * 7192849 initial commit
In this situation, GitLab could instead create new branch by
applying onto the old tip
* b02d02f (origin/feature-wip, feature-wip) Pushed | | * bec979c (HEAD -> gitlab-automatic-branch-xzy2342) Apply suggestion to foo (GitLab GUI) |/ | * 3edc93f Apply suggestion to foo (GitLab GUI) | * f9c2a59 Apply suggestion to foo (GitLab GUI) | * 034b71f WIP: foo | ... | * 7192849 initial commit
Then we could use normal git to merge those, or GitLab could automatically merge and only create a branch when it cannot merge without conflict.
So: we have a file-locking-like situation here. Until all the MR's discussion items are resolved, nobody can (should not) commit to that branch. Bummer.