Merge Conflicts and Target Updates in GitLab
Overview of MR workflow
We have two branches we are actively working on: Fork’s main-translation, and Upstream’s main/master.
Translation MRs, which are created by Argo, contain the latest translations from the Phrase TMS. They exist on the Forked projects.
Upstream Push MRs are created that copy the contents from main-translation to the Upstream projects. They do not copy any commits over, they instead create new commits, but with the exact same file contents, hence the dotted lines from main-translation to those MRs.
The Upstream pulls merge the commits upstream into main-translation every hour; any changes made upstream are copied back into main-translation.
Merge Conflicts
When merging two branches, git attempts to combine the histories of them seamlessly. The history in git is a series of changes on a per line basis. If the changes can be put together in a continuous sequence, then the merge can be done automatically without human intervention. In other words: no merge conflicts.
Conflicts arise when git cannot put together the series of changes seamlessly, because the changes on the merged branches conflict. The “starting point” or “base” of these branches is the last shared commit, and all the commits after that are what need to be merged together.
Only these commits, that come after the shared commit, can conflict.
In the case of our unique AI workflow, upstream pushes, and main-translation branch, we have a situation that can arise where changes on two different branches must be merged, creating a situation above where conflicts are possible.
The AI Upstream Push MR and the Human Translation MR is where the branches diverge, where they are making changes to files on the same lines. They are then combined when the Human Translation MR and the upstream pulls occur. In the event that target updates are made to the AI Upstream push MR, the Human Translation MR’s changes will conflict with that AI Upstream push MR’s changes. Either the conflicts will occur on the Upstream pull, or in the Human Translation MR, whichever is second to merge.
How to resolve merge conflicts caused by target updates
Please refer to the diagram above.
We consider what’s in the Upstream to be the source of truth. That means we assume the target updates in it are correct or preferred over the translations in the Fork. These target updates can originate from the following MRs.
- AI Translation MRs
- Human Translation MRs
- AI Upstream push MRs
- Human Upstream push MRs
- Community Target Update MRs
Therefore, @rasamhossain will automate the “Upstream pull (every hour)” process to automatically accept what’s in the Upstream if a merge conflict arises. If a merge conflict occurs in any MR, a human will review the conflict and accept what’s in the Upstream, unless the target update is clearly incorrect.
There is an assumption that the translation vendor will monitor the target updates in all MRs, make the necessary changes in the TM, and avoid overwriting the target updates in subsequent translation cycles. This is essentially an “Update TM" process. Unfortunately it isn’t automated at this point. The vendor should communicate to GitLab if they do not believe a target update is correct. See #683 for more details.
It is possible that a translation in the fork turns out to be the preferred one. In that case, the vendor will need to back out the corresponding target updates in the TM, and the subsequent translation process will overwrite the upstream target updates.