1

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 ?

David Bowman
  • 11
  • 3
  • What I think you should do is push into a _different_ branch so that you can create a PR to merge into `master`. Given that this branch is the result of merging `master` and `release`, it will be fine to merge with `master`. – eftshift0 Mar 24 '23 at 14:25
  • That's what I tried to do with the **resolve-conflict** branch and it works in the sense that the changes from release are on master but the issue is that I still have the conflict from **release** to **master**. This means if we had another commit without conflict to **release** we cannot merge it simply to master as it is blocked be the conflict that were never resolved from **release** to **master** – David Bowman Mar 24 '23 at 14:38
  • are you _squash-merging_ (or _rebase-merging_)? – eftshift0 Mar 24 '23 at 14:44
  • I use `git merge --no-ff ` to merge (form my understanding, this should avoid to fast-forward the commit and create an explicit merge commit) – David Bowman Mar 24 '23 at 15:32
  • duh, but of course. My bad. – eftshift0 Mar 24 '23 at 15:40
  • Ok.... that is on your side... _but_ I think you are **squash-merging** when you merge the MR **on gitlab**... and that would be why you are seeing that. Try with a real merge and it will behave as expected. – eftshift0 Mar 24 '23 at 15:42
  • Ooh indeed, the repository was set to check squash by default and when un-checking this setting, this had the effect expected ! If you can post the comment as an answer I'll accpet it ! Many thanks – David Bowman Mar 24 '23 at 16:14
  • No worries... it's an n-plicate. – eftshift0 Mar 24 '23 at 16:14
  • When you need to resolve conflicts in a way where you need to test some things locally, you could merge master into your dev branch first, fix all the issues, and then request your changes to be merged into master. This way, you can be sure that your dev branch is up to date with changes that happened on the master in the mean time. – Torge Rosendahl Mar 25 '23 at 17:37

1 Answers1

0

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)

David Bowman
  • 11
  • 3