Proposal: renaming 'master' branch to 'main'
I don't recall exactly when it first came up, but it has been a few years now since the idea of moving away from 'master' as the git default branch name became a topic in OSS communities. Far from the first mention: https://sfconservancy.org/news/2020/jun/23/gitbranchname/ Both gitlab.com and github.com now default to 'main' as the default branch when creating new repositories: https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/ https://github.blog/changelog/2020-10-01-the-default-branch-for-newly-create... Some notable large open source projects have done, (or at least started) to rename the default branch in their existing projects too. eg GNOME: https://gitlab.gnome.org/GNOME/glib/-/issues/2348 Fedora: https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main For libosinfo we did a rename last year. There was a little disruption but nothing too terrible, IIRC, missing weblate translation branch update was our main mistake. I'd suggest it is time to libvirt to get on this train and rename our default branch to 'main' in all repositories. There are essentially two options * Rename 'master' to 'main' With this, anyone pulling from an existing checkout will get an error telling them that 'master' does not exist. It won't tell them about 'main', but at least it gives them a sign that something in their checkout probably needs changing. Downside is that any URLs pointing to source files / commits with a branch name in the URL will become 404s. * Clone 'master' to 'main' With this, anyone pulling from an existing checkout will get no updates. It is very easy for people to not realize that they are tracking a branch which is no longer used Downside is also that the undesirable term 'master' remains present in the repo, even if unused. We might also miss places which still refer to 'master' which will end up outdated Ideally, we would rename 'master' to 'main', while the git server adds 'symbolic-ref' to effectively create a symlink to 'main'. This would mean anyone pulling from 'master' would get content from 'main'. AFAICT, this is not supported by gitlab.com though. I had held off suggesting the rename, hoping such support might arrive, but I'm doubting it will happen on a timescale to be useful, if at all. In terms of impact * Developers need to checkout 'main' and delete their now stale 'master' branch * Any open merge requests need updating, hitting 'Edit' and choose the new 'main' as the target * User repo forks may wish to delete their 'master' and push 'main', but that's entirely optional, since many people never touch/look at the default branch in their forks. * CI mostly shouldn't be impacted since we use CI_DEFAULT_BRANCH most places instead of hardcoding 'master'. A few exceptions - Links to artifacts include a branch name - integration tests mention branch name - References to check-doc/cirrus-run jobs use 'master' as the docker tag * GitHub mirroring won't track the rename, it'll just add 'main' without removing 'master', so needs manual fixup. * Need to update 'protected branch' and 'default branch' fields in gitlab repo settings for each repo * Weblate needs updating to translate from 'main' instead of 'master' So the rename isn't free of cost, but it should all be one-time only costs, which I think is something we can live with. Given our never ceasing development stream there's not really any 'right' time todo such a change. Just after a release is probably as good as it gets, and January is marginally better since we skip Feb and have a 6 week gap until the March 1st release. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Mon, Jan 16, 2023 at 02:55:10PM +0000, Daniel P. Berrangé wrote:
I don't recall exactly when it first came up, but it has been a few years now since the idea of moving away from 'master' as the git default branch name became a topic in OSS communities. Far from the first mention:
https://sfconservancy.org/news/2020/jun/23/gitbranchname/
Both gitlab.com and github.com now default to 'main' as the default branch when creating new repositories:
https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/ https://github.blog/changelog/2020-10-01-the-default-branch-for-newly-create...
Some notable large open source projects have done, (or at least started) to rename the default branch in their existing projects too. eg
GNOME: https://gitlab.gnome.org/GNOME/glib/-/issues/2348 Fedora: https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
For libosinfo we did a rename last year. There was a little disruption but nothing too terrible, IIRC, missing weblate translation branch update was our main mistake.
I'd suggest it is time to libvirt to get on this train and rename our default branch to 'main' in all repositories.
There are essentially two options
* Rename 'master' to 'main'
With this, anyone pulling from an existing checkout will get an error telling them that 'master' does not exist. It won't tell them about 'main', but at least it gives them a sign that something in their checkout probably needs changing.
Downside is that any URLs pointing to source files / commits with a branch name in the URL will become 404s.
* Clone 'master' to 'main'
With this, anyone pulling from an existing checkout will get no updates. It is very easy for people to not realize that they are tracking a branch which is no longer used
Downside is also that the undesirable term 'master' remains present in the repo, even if unused. We might also miss places which still refer to 'master' which will end up outdated
We can also then remove everything from master and just keep a README file explaining the situation.
Ideally, we would rename 'master' to 'main', while the git server adds 'symbolic-ref' to effectively create a symlink to 'main'. This would mean anyone pulling from 'master' would get content from 'main'. AFAICT, this is not supported by gitlab.com though. I had held off suggesting the rename, hoping such support might arrive, but I'm doubting it will happen on a timescale to be useful, if at all.
In terms of impact
* Developers need to checkout 'main' and delete their now stale 'master' branch
* Any open merge requests need updating, hitting 'Edit' and choose the new 'main' as the target
* User repo forks may wish to delete their 'master' and push 'main', but that's entirely optional, since many people never touch/look at the default branch in their forks.
* CI mostly shouldn't be impacted since we use CI_DEFAULT_BRANCH most places instead of hardcoding 'master'. A few exceptions
- Links to artifacts include a branch name - integration tests mention branch name - References to check-doc/cirrus-run jobs use 'master' as the docker tag
* GitHub mirroring won't track the rename, it'll just add 'main' without removing 'master', so needs manual fixup.
* Need to update 'protected branch' and 'default branch' fields in gitlab repo settings for each repo
* Weblate needs updating to translate from 'main' instead of 'master'
Any custom tooling (local) needs updates too, I've done mine already last year to accomodate for both branch names.
So the rename isn't free of cost, but it should all be one-time only costs, which I think is something we can live with. Given our never ceasing development stream there's not really any 'right' time todo such a change. Just after a release is probably as good as it gets, and January is marginally better since we skip Feb and have a 6 week gap until the March 1st release.
If you include the time left for people to notice (time_of_change - time_of_announcement) then we can give people more time after another release, but it would probably end up being the same time. No objections from me for either of the options above. Godspeed, Martin
With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Jan 17, 2023 at 09:02:23AM +0100, Martin Kletzander wrote:
On Mon, Jan 16, 2023 at 02:55:10PM +0000, Daniel P. Berrangé wrote:
I'd suggest it is time to libvirt to get on this train and rename our default branch to 'main' in all repositories.
There are essentially two options
* Rename 'master' to 'main'
With this, anyone pulling from an existing checkout will get an error telling them that 'master' does not exist. It won't tell them about 'main', but at least it gives them a sign that something in their checkout probably needs changing.
Downside is that any URLs pointing to source files / commits with a branch name in the URL will become 404s.
* Clone 'master' to 'main'
With this, anyone pulling from an existing checkout will get no updates. It is very easy for people to not realize that they are tracking a branch which is no longer used
Downside is also that the undesirable term 'master' remains present in the repo, even if unused. We might also miss places which still refer to 'master' which will end up outdated
We can also then remove everything from master and just keep a README file explaining the situation.
I like this option. It removes the guesswork, while still making the change visible in a very obvious way. We can then drop the master branch for good after a Reasonable Amount of Time™ has passed. At this point, most of the projects that I interact with outside of the libvirt organization have switched away from having a "master" branch, mostly adopting "main" as the new name. So making the change would make things more consistent on my side, and I'm for it. -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Jan 17, 2023 at 09:02:23AM +0100, Martin Kletzander wrote:
On Mon, Jan 16, 2023 at 02:55:10PM +0000, Daniel P. Berrangé wrote:
I don't recall exactly when it first came up, but it has been a few years now since the idea of moving away from 'master' as the git default branch name became a topic in OSS communities. Far from the first mention:
https://sfconservancy.org/news/2020/jun/23/gitbranchname/
Both gitlab.com and github.com now default to 'main' as the default branch when creating new repositories:
https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/ https://github.blog/changelog/2020-10-01-the-default-branch-for-newly-create...
Some notable large open source projects have done, (or at least started) to rename the default branch in their existing projects too. eg
GNOME: https://gitlab.gnome.org/GNOME/glib/-/issues/2348 Fedora: https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
For libosinfo we did a rename last year. There was a little disruption but nothing too terrible, IIRC, missing weblate translation branch update was our main mistake.
I'd suggest it is time to libvirt to get on this train and rename our default branch to 'main' in all repositories.
There are essentially two options
* Rename 'master' to 'main'
With this, anyone pulling from an existing checkout will get an error telling them that 'master' does not exist. It won't tell them about 'main', but at least it gives them a sign that something in their checkout probably needs changing.
Downside is that any URLs pointing to source files / commits with a branch name in the URL will become 404s.
* Clone 'master' to 'main'
With this, anyone pulling from an existing checkout will get no updates. It is very easy for people to not realize that they are tracking a branch which is no longer used
Downside is also that the undesirable term 'master' remains present in the repo, even if unused. We might also miss places which still refer to 'master' which will end up outdated
We can also then remove everything from master and just keep a README file explaining the situation.
Oh, I should have mentioned that as an option, and said that I consider it undesirable. That delete commit effectively forks 'master' history from 'main', meaning there's no way back from the rename. We did this for some of the stable branches in libvirt in the past and I really regret that, we should have just left them idle IMHO. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On a Monday in 2023, Daniel P. Berrangé wrote:
There are essentially two options
* Rename 'master' to 'main'
With this, anyone pulling from an existing checkout will get an error telling them that 'master' does not exist. It won't tell them about 'main', but at least it gives them a sign that something in their checkout probably needs changing.
Downside is that any URLs pointing to source files / commits with a branch name in the URL will become 404s.
Commits should not be an issue, the hash is enough to identify them. The links to 'blob's including 'master' do not reference any commits so they would be prone to braking if we move the files around anyway.
* Clone 'master' to 'main'
With this, anyone pulling from an existing checkout will get no updates. It is very easy for people to not realize that they are tracking a branch which is no longer used
Downside is also that the undesirable term 'master' remains present in the repo, even if unused. We might also miss places which still refer to 'master' which will end up outdated
Due to the nature of git, it will stay in the history anyway. But I think it's better not to mislead people and delete/rename the branch completely, if a redirect is not possible. Jano
Ideally, we would rename 'master' to 'main', while the git server adds 'symbolic-ref' to effectively create a symlink to 'main'. This would mean anyone pulling from 'master' would get content from 'main'. AFAICT, this is not supported by gitlab.com though. I had held off suggesting the rename, hoping such support might arrive, but I'm doubting it will happen on a timescale to be useful, if at all.
On 1/16/23 07:55, Daniel P. Berrangé wrote:
I don't recall exactly when it first came up, but it has been a few years now since the idea of moving away from 'master' as the git default branch name became a topic in OSS communities. Far from the first mention:
https://sfconservancy.org/news/2020/jun/23/gitbranchname/
Both gitlab.com and github.com now default to 'main' as the default branch when creating new repositories:
https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/ https://github.blog/changelog/2020-10-01-the-default-branch-for-newly-create...
Some notable large open source projects have done, (or at least started) to rename the default branch in their existing projects too. eg
GNOME: https://gitlab.gnome.org/GNOME/glib/-/issues/2348 Fedora: https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
For libosinfo we did a rename last year. There was a little disruption but nothing too terrible, IIRC, missing weblate translation branch update was our main mistake.
I'd suggest it is time to libvirt to get on this train and rename our default branch to 'main' in all repositories.
There are essentially two options
* Rename 'master' to 'main'
I slightly prefer this option, which is the one taken by virt-manager IIRC. Regards, Jim
With this, anyone pulling from an existing checkout will get an error telling them that 'master' does not exist. It won't tell them about 'main', but at least it gives them a sign that something in their checkout probably needs changing.
Downside is that any URLs pointing to source files / commits with a branch name in the URL will become 404s.
* Clone 'master' to 'main'
With this, anyone pulling from an existing checkout will get no updates. It is very easy for people to not realize that they are tracking a branch which is no longer used
Downside is also that the undesirable term 'master' remains present in the repo, even if unused. We might also miss places which still refer to 'master' which will end up outdated
Ideally, we would rename 'master' to 'main', while the git server adds 'symbolic-ref' to effectively create a symlink to 'main'. This would mean anyone pulling from 'master' would get content from 'main'. AFAICT, this is not supported by gitlab.com though. I had held off suggesting the rename, hoping such support might arrive, but I'm doubting it will happen on a timescale to be useful, if at all.
In terms of impact
* Developers need to checkout 'main' and delete their now stale 'master' branch
* Any open merge requests need updating, hitting 'Edit' and choose the new 'main' as the target
* User repo forks may wish to delete their 'master' and push 'main', but that's entirely optional, since many people never touch/look at the default branch in their forks.
* CI mostly shouldn't be impacted since we use CI_DEFAULT_BRANCH most places instead of hardcoding 'master'. A few exceptions
- Links to artifacts include a branch name - integration tests mention branch name - References to check-doc/cirrus-run jobs use 'master' as the docker tag
* GitHub mirroring won't track the rename, it'll just add 'main' without removing 'master', so needs manual fixup.
* Need to update 'protected branch' and 'default branch' fields in gitlab repo settings for each repo
* Weblate needs updating to translate from 'main' instead of 'master'
So the rename isn't free of cost, but it should all be one-time only costs, which I think is something we can live with. Given our never ceasing development stream there's not really any 'right' time todo such a change. Just after a release is probably as good as it gets, and January is marginally better since we skip Feb and have a 6 week gap until the March 1st release.
With regards, Daniel
On Mon, Jan 16, 2023 at 02:55:10PM +0000, Daniel P. Berrangé wrote:
I'd suggest it is time to libvirt to get on this train and rename our default branch to 'main' in all repositories.
There are essentially two options
* Rename 'master' to 'main'
With this, anyone pulling from an existing checkout will get an error telling them that 'master' does not exist. It won't tell them about 'main', but at least it gives them a sign that something in their checkout probably needs changing.
Downside is that any URLs pointing to source files / commits with a branch name in the URL will become 404s.
I'm going to go with this option, since it fully eliminates 'master' from usage immediately.
* Clone 'master' to 'main'
With this, anyone pulling from an existing checkout will get no updates. It is very easy for people to not realize that they are tracking a branch which is no longer used
Downside is also that the undesirable term 'master' remains present in the repo, even if unused. We might also miss places which still refer to 'master' which will end up outdated
In terms of impact
snip
So the rename isn't free of cost, but it should all be one-time only costs, which I think is something we can live with. Given our never ceasing development stream there's not really any 'right' time todo such a change. Just after a release is probably as good as it gets, and January is marginally better since we skip Feb and have a 6 week gap until the March 1st release.
Well obviously I missed that time frame. What I'm intending todo, right now, is start with the repos that are fairly infrequently / rarely touched: libvirt-appdev-guide-python libvirt-cim libvirt-console-proxy libvirt-csharp libvirt-designer libvirt-devaddr libvirt-gitlab-executor libvirt-media libvirt-publican libvirt-sandbox libvirt-sandbox-image libvirt-security-notice libvirt-snmp libvirt-test-API virttools-planet virttools-web these shouldn't cause disruption to anyone, and will let me practice the CI updates / gitlab settings changes. After that, then progress to the somewhat active repos, but which are NOT on the fixed monthly release schedule: libvirt-ci libvirt-dbus libvirt-glib libvirt-java libvirt-ocaml libvirt-php libvirt-rust libvirt-tck libvirt-wiki Open merge requests we need their target branch flipping, which IIUC is trivial. I'll send another mail before starting on these repos. Then finally, just after March 1st, do the repos which have monthly releases schedule (assuming all previous conversions have worked as expected). libvirt libvirt-go-module libvirt-go-xml-module libvirt-perl libvirt-python again, before I start on this last set of 5, I'll send another warning message a day-ish before. I'm not intending to touch any of the repos marked as 'archived' in the gitlab UI at this time. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
participants (5)
-
Andrea Bolognani -
Daniel P. Berrangé -
Jim Fehlig -
Ján Tomko -
Martin Kletzander