Notes regarding "Require branches to be up to date before merging"

[petertseng]

They're in #444

I just created this issue to help me find them easier.

If we revert it:

For the situation of "Branches A and B individually pass the tests, but together they would fail", the procedure of:

• Merge A
• Click "Restart build" on B

will then cause the Travis CI check for B to fail (as it should), but the disadvantage is we'd have to remember to click that "Restart build" button, and we might forget (because we are all human).

So we will leave it as is for now!

I don't need comments on this issue, I'm going to close it immediately.

I think I would like an email for this though, so maybe someone could comment on it and then delete their comment (if necessary)?

[rbasso]

Commenting just to notify @petertseng.

[petertseng]

I got really annoyed that I created 6 PRs in a row (#525, #526, #527, #528, #529, #530), but the "Require branches to be up to date before merging" would have forced me to merge one, update the next one, wait 5 minutes for build to pass, and so on, taking 25+ minutes to merge the PRs. After merging the first two, I got fed up and just octopus merged the other four.

381d339

command-line only, and you have to make Travis build that commit on a branch before it can be pushed to master, but at least it's better than waiting 5 minutes per PR.

[petertseng]

That means ultimately I don't need this setting changed, since I (finally!) found a way to fit it into my workflow (octopus merge) that doesn't make me go insane.

However, if octopus merges make anyone other than me go insane, then the only way to resolve our differences may be in fact to change that setting. Because I will go insane without octopus merges.

[rbasso]

Ideally, this setting makes sense, but I also think that it is annoying.

The probability of having commits that pass individual tests but fail the combined ones is remote and would be detected in the next PR. So it seems that there is almost no risk in disabling it.

Feel free to ask Katrina to disable it. 👍

[petertseng]

Hmm, now I'm not sure how I got the octomerge to work last time. I'll keep trying a bit but eventually I may have to merge without it if I can't figure it out.

[petertseng]

Okay that worked... variables to check:

• Does it matter whether approvals on all PRs need to be for the latest commit on that PR? I thought yes this time, but wasn't sure - see how I needed to ask for re-approval on luhn 1.0.0.2: only test isValid, use (most) x-common cases #533, phone-number 1.2.0.3: enforce area/exchange not starting with 1 #534
• Does it matter whether master is listed as one of the parents of the merge commit? Is it OK for master not to be listed, if branches are fast-forwards? I thought master must be listed as one of the parents, but also unsure. It is known that it works if master is listed, but unknown whether it works if master is not.

I was unsure because originally the merge got rejected, but I couldn't tell which of the two factors it was.

[petertseng]

Historical notes: Octomerges performed in this repo:

• 381d339
• a142b26

I wrote down the former, but not the latter.