<div dir="auto"><div>Hey, the point of the thing is not to add a thing called "main" but to get rid ot the thing called "master" which your plan fails to accomplish. If we go there, go all-in. <br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">чц, 14 сту 2021, 01:08 карыстальнік Sandro Santilli <<a href="mailto:strk@kbt.io">strk@kbt.io</a>> напісаў:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Following a recent chat on IRC about a motion, on mapserver-dev<br>
mailing list, for renaming the "master" branch to "main", to<br>
avoid a word which "trivializes a horrific time in history by<br>
re-using the conceptual framework of legalized human ownership for<br>
piddly computer stuff", I've been studying solutions that would make<br>
such transition less painful then when we decided to rename the<br>
main branch from "trunk" to "master"...<br>
<br>
Doing a simple rename would entail:<br>
<br>
  - Changing all "master" references in CI badges<br>
    (in the README.md of each branch, and on the wiki)<br>
<br>
  - Changing all "master" references in CI configurations<br>
<br>
  - Updating all developers clones remotes HEAD refenrece<br>
    to point to the new branch<br>
<br>
  - Updating all pull requests on all git hosters to still<br>
    point at the main branch (optional, for mirrors, as we<br>
    merge those ones manually anyway).<br>
<br>
The above can be painful, but what if we can have the _same_ branch<br>
referenced as both "main" and "master" until all of the above is done ?<br>
<br>
Well, the good new is that WE CAN !<br>
<br>
The `git` tool supports "symbolic references", so we could keep a<br>
"refs/heads/master" reference be a kind of symbolic link to<br>
"refs/heads/main", so that all users will see 2 branches ("master"<br>
and "main") and will be able to push to any of the two while seeing<br>
the change effectively applied to both.<br>
<br>
Such "symbolic references" are not supported by the git protocol,<br>
so they cannot be created on a remote from the client, but we DO<br>
have access to our official repository (we would NOT have this, if<br>
our official repository was on GitHub) so we can do this.<br>
<br>
I've done this "symbolic reference" setup on a staging host at osgeo:<br>
<br>
  <a href="https://dev.git.osgeo.org/gitea/postgis/postgis" rel="noreferrer noreferrer" target="_blank">https://dev.git.osgeo.org/gitea/postgis/postgis</a><br>
<br>
You'll see that the default branch there is called "main".<br>
If you clone that repository your local clone will have the "main"<br>
branch checked out. But you'll also see a "main" branch, and whether<br>
you push to "main" or to "master", your changes will be visible in<br>
both branches.<br>
<br>
Mirroring should still work, even if mirroring will loose symbolic<br>
references (references will become "hard"). On mirrors this should not<br>
be a problem because branches in mirrors are always overridden by the<br>
mirroring script, so it doesn't matter.<br>
<br>
So, would you like me to do this in production ?<br>
<br>
--strk;<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank" rel="noreferrer">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
</blockquote></div></div></div>