Inconsistent handling of ambiguous merge bases in a merge request
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
Usually, there is exactly one merge-base for two branches (e.g. MR branch and its target branch). In some situations, there can be multiple possible merge bases. The example below illustrates a situation with two candidate merge bases - both of the bases are contained in the target branch as well as the MR, but the bases themselves don't contain the other one.
* <------- target
|\
* |
| *
| | * <--- MR
| |/|
|/| *
* |/ <---- base 1
| * <----- base 2
|/
*Since the merge base is used to calculate the changes of a MR and also to calculate the affected code to determine code owners, the ambiguity can lead to unexpected information shown on the MR.
In the current implementation, the calculation of changes and code owners even take different bases -> code owner approval required for changes that don't show up in changes tab (or the other way round).
Steps to reproduce
- create a situation with ambiguous merge-bases (e.g. the one from the example above)
- make sure that the diff between the ambiguous merge-bases affects owners that are not affected by the changes along the MR branch otherwise
- create an MR
- compare code owner approval requirements with diff shown in changes tab
What is the current bug behavior?
Changes and code owners inconsistent + not clear for the user which diff is used in the first place.
What is the expected correct behavior?
At least code owners and changes should use the same base - IMO, there should also be a warning about the situation with a hint on how to solve the problem (i.e. merge the target branch or rebase).