[postgis-devel] Make "master" branch also available as "main"

[Sandro Santilli]

Following a recent chat on IRC about a motion, on mapserver-dev
mailing list, for renaming the "master" branch to "main", to
avoid a word which "trivializes a horrific time in history by
re-using the conceptual framework of legalized human ownership for
piddly computer stuff", I've been studying solutions that would make
such transition less painful then when we decided to rename the
main branch from "trunk" to "master"...

Doing a simple rename would entail:

  - Changing all "master" references in CI badges
    (in the README.md of each branch, and on the wiki)

  - Changing all "master" references in CI configurations

  - Updating all developers clones remotes HEAD refenrece
    to point to the new branch

  - Updating all pull requests on all git hosters to still
    point at the main branch (optional, for mirrors, as we
    merge those ones manually anyway).

The above can be painful, but what if we can have the _same_ branch
referenced as both "main" and "master" until all of the above is done ?

Well, the good new is that WE CAN !

The `git` tool supports "symbolic references", so we could keep a
"refs/heads/master" reference be a kind of symbolic link to
"refs/heads/main", so that all users will see 2 branches ("master"
and "main") and will be able to push to any of the two while seeing
the change effectively applied to both.

Such "symbolic references" are not supported by the git protocol,
so they cannot be created on a remote from the client, but we DO
have access to our official repository (we would NOT have this, if
our official repository was on GitHub) so we can do this.

I've done this "symbolic reference" setup on a staging host at osgeo:

  https://dev.git.osgeo.org/gitea/postgis/postgis

You'll see that the default branch there is called "main".
If you clone that repository your local clone will have the "main"
branch checked out. But you'll also see a "main" branch, and whether
you push to "main" or to "master", your changes will be visible in
both branches.

Mirroring should still work, even if mirroring will loose symbolic
references (references will become "hard"). On mirrors this should not
be a problem because branches in mirrors are always overridden by the
mirroring script, so it doesn't matter.

So, would you like me to do this in production ?

--strk;