I saw that tweet from the current CEO Of Microsoft owned GitHub, and even CDNET seems to know from "internal sources" at github that it was not just a tweet.
The rename is for every clone and fork out there, for every developper that has collaborated, and for all the CI / CD services (Travis, Jenkins) and targets (PyPi, Conda) ... they are downstream. For example, certain build and publish (python packages let's say) actions are only taken on specific branches. Some of them, like "features" or "develop" are never "built" or published to a repository. This is usually configured in the CI / CD files _inside_ the repositories. So It's also a matter of modifying the actual contents of the repositories, not only the name.
I agree, it will take 5 minutes to the person creating the repository, until github comes up with a new default branch name.
a) The actual instructions you point to are to change what is known as the default branch. This could as well be "release". Not directly related to a new default branch name. _But_ indeed, this shows that you can right now use github with a new default branch name.
b) and c) look to me like the perfect recipe to complicate a world that was already not very easy. Let's face it, git has been known to be more complicated than mercurial for example. The fact that you can do so many cool things with git like "pre-commit" hooks, templates, worktrees and so on, comes at the price of complexity of the tool. So if I can stay with a regular "git init" in _any_ remote headless server I can work with, (or a git clone) instead of having to create a new template plus remember the new default branch name of the particular organization (inside github for example) I will do it that way.
For BONSAI, when we talk practical terms this means less than 35 repositories, so I suppose the 5 minutes for every potential bonsai contributor can be safely spent. Hey, maybe once github finds the right way to push this down, they'll even allow groups or organization for an automatic way to do it for all their projects (after all, a git -m is relatively fast on the server side). However, don't forget that this means every clone out there of our repos might need an update.
In my personal daily experience I deal with gitlab.com / github.com / bitbucket.com / local gitlab instances daily, and, clearly this will be not just 5 minutes once (like this week for example). It's going to be 5 minutes daily for a few weeks.
I suggest we wait until
+ github.com proposes:
- a way to do it from the web interface that matches a github wide policy
- a huge communication campaign that warns all github users (professional / free-lance / occasional / consultant developers, community managers, savy tech users, scientific programmers, you-name-it) of the *name* of the new default branch
+ a consensus [on a sensitive new default name] emerges:
- from the BONSAI community (General Assembly, we're looking at you)
- also from the wider git users community in the world
.. and optionally it would be interesting to hear from this "2 hit-wonder" guy named Linus Torvalds, on how he is going to deal with it. Not that we should follow his own practices, because the python community ones seem a bit less tyrannic.
To sum up, I'm not against it. All I say is that we can decide now to GO or NO-GO on a BONSAI wide level for the change of the current default branch of all our github repositories (because they are all hosted there, but they are all just "git" repositories), but before executing this, let's see how the wider world community handles the case.