Re: main != master at github.com/git/git

[Junio C Hamano <gitster@pobox.com>]

<rsbecker@nexbridge.com> 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.