merge conflicts avoidable?

Stream: nightly-testing

[Joachim Breitner]

Which script is that again?
(Found it. :eyes: )

[Joachim Breitner]

I see three merge operations that might have conflicts (master into bump, nightly into adaption branch, adaption branch back into nightly) . Do you remember which of the two had conflicts?

[Joachim Breitner]

One cause for unnecessary merge conflicts could be that adaption branches are squash-merged into bump/v4.11.0, so as soon as you merge back into nightly-testing or a new adaption branch, you’ll get unnecessary merge conflicts. Just like with stashed PRs against master.

This can be mitigated by some additional merges: After bump/nightly-2024-07-22 got merged into bump/v4.11.0 (squash merge), if one then merges that squash merge commit back to bump/nightly-2024-07-22, that should go without conflict, but effectively tells git about the relation between the squashed commit and the original branch. Merging that back into nightly-testing should then convey that information, and hopefully avoid merge conflicts. (Assuming I am barking at the right tree.)

If the bump PRs are applied cleanly (i.e. bump/nightly-2024-07-22 is up do date with regard to bump/4.11.0 and after the merge, bump/nightly-2024-07-22 is identical to the tip of bump/nightly-2024-07-22), then running git post-squash bump/4.11.0 (from https://github.com/nomeata/git-post-squash) on nightly-testing should achieve the same result.

Not sure how friction these conflicts cause for you; if they do annoy you I’m happy to help here.

[Johan Commelin]

@Joachim Breitner It was the first two. The conflict was identical, just that the first time I wanted theirs, and the 2nd time I wanted ours.

[Johan Commelin]

In this case the friction was small. But if there are 20 conflicts, and you fix all of them, and then you need to do all of them again... that's quite annoying. And that has happened.

[Johan Commelin]

So I would be happy to experiment with ways to reduce the friction.
I still think rerere might also be a good solution to try out

[Notification Bot]

6 messages were moved here from #nightly-testing > #15046 adaptations for nightly-2024-07-22 by Joachim Breitner.

[Joachim Breitner]

I’ll have a look when the next one is due.

[Joachim Breitner]

The first step of the script seems to be merging master into bump/v4.11.0. Two questions:

• Here merge conflicts are expected, right? If something changes in master that had to be touched for adaption, this conflict is unavoidable.
• The script pushed to the bump branch; here it fails with GH006: Protected branch update failed for refs/heads/bump/v4.11.0.. Is this a priviledged operation performed by just a few people? Do you manually locally check that your merges still compile?

[Joachim Breitner]

Indeed I do get a second merge conflict when merging origin/nightly-testing into bump/nightly-2024-07-23, but it’s not identical (or identical-but reversed).

[Joachim Breitner]

Hmm, I don’t see anything easy to improve here. The conflicts don't seem to stem from squash-merging into the bump branch.
Maybe it’s a bit less confusing to create the adaption branch the other way around, so instead of

# on bump/v4.11.0
git checkout -b "bump/nightly-$NIGHTLYDATE"
git merge origin/nightly-testing

do

# on origin/nightly-testing
git checkout -b "bump/nightly-$NIGHTLYDATE"
git merge bump/v4.11.0

This might make conflicts a bit easier to recognize.

[Joachim Breitner]

In fact, Is there a good reason to not merge bump/v4.11.0 to nightly-testing first, and then create the adaption branch from that, as opposed to merging bump/v4.11.0 into the new branch later merging that into nightly-testing?

[Joachim Breitner]

( :tree: :juggling: )

[Joachim Breitner]

Hmm, maybe one way to avoid this is if instead of having both master → nightly-testing and master → bump/v4.11.0 propagation happening in parallel (thus requiring separate merges, and then again a conflict), new commits would go through it linearly: master → bump/v4.11.0 and bump/v4.11.0 → nightly-testing.

What is the quality expectation for bump/v4.11.0? Always green?

[Ruben Van de Velde]

Yeah

[Johan Commelin]

Joachim Breitner said:

• The script pushed to the bump branch; here it fails with GH006: Protected branch update failed for refs/heads/bump/v4.11.0.. Is this a priviledged operation performed by just a few people? Do you manually locally check that your merges still compile?

We don't check this locally. Of course there is a risk that we break something by merging master into bump/v4.11.0. But at least before the merge, both branches ought to pass CI. If we create problems, we currently have to fix them by hand afterwards.

[Kim Morrison]

Joachim Breitner said:

Hmm, maybe one way to avoid this is if instead of having both master → nightly-testing and master → bump/v4.11.0 propagation happening in parallel (thus requiring separate merges, and then again a conflict), new commits would go through it linearly: master → bump/v4.11.0 and bump/v4.11.0 → nightly-testing.

What is the quality expectation for bump/v4.11.0? Always green?

The current plan is that bump/v4.11.0 is green except in the window after a manual merge of master into it (which might break things) and before the next bump/nightly-YYYY-MM-DD is merged into it (which is expected to pass CI).

[Joachim Breitner]

I see. Or put differently, if I may rephrase: it morally jumps from adoption branch merge to adoption branch merge, and the manual merge of master before the adoption branch is mostly for the benefit of keeping the git history complete.