I have a question about a problem when merging branches after resolving conflict in Gitlab. The conflict is not the issue in itself but I fail to understand what is happening under the hood. The setup is the following: I have two long lived branch in Gitlab called release and master and I merge the release branch to master from time to time.
The issue I have is that I cannot resolve conflicts without pushing directly to master, which is disabled in the setting of the repository.
To resolve the conflict, I opened a merge request, let's call it MR1, to merge the release branch into master. I followed the steps recommended by Gitlab to resolve locally:
git fetch origin
git checkout -b 'release' 'origin/release
git fetch origin
git checkout 'master'
git merge --no-ff 'release'
# resolve conflict and add them
git merge --continue
My only issue is that the last command require to push directly to master, which is not authorized by default in my repository settings:
git push origin 'master' # I cannot do this directly
So I instead, the way I usually resolve this on other repository is to create another branch resolve-conflict containing the merge commit between branch release and master and open another merge request, let's call it MR2, targeting master. The state of the graph between my three branches looks like this so all looks good to me:
resolve-conflict
/ |
/ |
/ |
/ |
/ |
release master
| |
| |
| |
| |
So this seems that I have effectively branch containing a merge commit (resolve-conflict) with two parents, release and master. After merging MR2, I expect the conflict I have in MR1 to be resolved (and merged automatically by Gitlab, this is how I successfully did in other repository). However after merging MR2 the conflict are still present in MR1 and the state of the graph is the following:
resolve-conflict
/ |
| |
| |
\ |
\ |
release \ master
| |
| |
| |
| |
The only way I found to resolve truly resolve the conflict is to modify my repository setting and pushing directly to master to unblock this situation (in this case the graph keeps the merge commit and the two parents release and master), however it is only a one-time fix and the next time I have a conflict, I need allow push to master directly.
We also switched from "Fast-forward" only to "merge commit" setting in Gitlab some time ago, I wonder if this can have an impact on this ?
As @eftshift0 pointed out in the comments, the issue was coming from the server side, Gitlab had "squash commit" set to encourage, meaning by default Gitlab was squashing the commit. This rewrote my commit (losing one of the parent int the process)
By un-selecting the "squash commit" option in Gitlab UI, the merge commit was not rewritten (keeping the two parents) and it correctly resolved the conflict (as it did locally)