<rsbecker@xxxxxxxxxxxxx> writes: > Would it not be more convenient just to add a GitHub action that > set main = master for each push? If "my private working area calls the primary integration branch 'master', but for publishing repositories, I have to push it twice, once to 'master' and then to 'main'" were the problem, the solution I would rather want to see implemented is to an ability for the repository owners to set a symref that makes 'main' refer to 'master', so that I do not have to worry about the aliasing. But it is not a problem (the push refspec can be set up to send the same commit to two different branches just fine). In any case, I am not sure if it would solve the problem being discussed: when CI runner sees branches updated to commit that hasn't been worked on, a new job is created to work on that commit, and updating two branches with the same commit at the same time unfortunately means two independent CI jobs work on the same commit in parallel. The 'lagging behind by 24 hours' hack I mentioned earlier was one way to work it around, but it would confuse folks. I'd really prefer not to special case 'main' (or 'master' for that matter), primarily because some downstreams rely more heavily on 'main' as Peff pointed out, but also because the problem is not 'master' vs 'main'. If 'next' happens to become empty soon after a new cycle starts and points at the same commit as 'master', we will see the same waste of cycles between 'master' and 'next'. Thanks.
