Understanding our merge and branch strategy
When testing what happens if I from my fork make a trivial change in README and apply the copy_mr:next label I now see 16 additional commits:
The original MR with 2 commits:
The copied MR with 16 additional commits:
When using master as source for a dev-branch and when master has previous commits that next does not, e.g. a previous MR only to master and not to next - then these commits will be added to the current MR to next since they are not already there. This is a behaviour we do not want.
So our procedure of using master as source and automatically copying to next works only if there are commits on next that are not on master, but not the other way around.
There are 16 additional commits in the next MR. There are quite a lot right now, due to some mishappenings before/during summer.
So I will try to figure out what to do in these cases. I could do some manipulation in the automatic copying procedure, reverting for instance merge commits to master which we know we do not want in next. But in the cases where there are actual commits on master that are only for master (like !1444 (merged)) then we are stuck. In this situation using master as a source branch to next does not work.
Will have to think and figure out some good mostly fool-proof procedure for this. Maybe at the point we have something on master which is not for next we need to actually have an arc6 branch. In the same way as when we want commits to ARC 7 that we do not want for ARC 6 we need a next branch.