Rename the "master" branch to "main"

[keszybz]

See seccomp/libseccomp#255. We should do the same.

Quoting here to make the discussion easier:

The steps are simple:
1. Rename the local git repostory: git branch -m master main
2. Push the "main" branch to GitHub: git push origin main
3. Switch the default branch on GitHub to "main" (see Settings -> Branches)
4. Merge any outstanding PRs against "master" into "main"
5. Update the badges in README.md to reference the "main" branch
6. Once all PR's referencing "master" have been merged, delete the "master" branch: git push origin :master

Re 4.: in our case, we have too many outstanding PRs, so for a while we'll have to deal with PRs submitted for the wrong branch. We can use manual merges. I have a local git macro for this, and it works well enough.

[boucman]

is there any sort of pre-merge github hook that could help here ? make master a protected branch ?

[keszybz]

I guess that'd help in avoiding mistakes. We can live without it, because we have a small group of people who do merges regularly, so I think we can just agree to follow a certain procedure, but a hook would make things more errorproof. Once we delete the master branch, this will stop being an issue.

[poettering]

sounds ok to me, but maybe let's do that in the beginning of a cycle, i.e. right after we released 247?

[pcmoore]

FYI, it looks like GH is working on a way to rename master without blowing up existing issues/PRs.

• https://github.com/github/renaming

[poettering]

@pcmoore thank you very much for that link. that's useful! much appreciated

[yuwata]

Several links:

• Inclusive Naming Initiative's word replacement list
  https://inclusivenaming.org/language/word-list

• Why renaming Git’s master branch is a terrible idea
  https://felipec.wordpress.com/2020/11/13/git-master/

[pcmoore]

FYI, it looks like the GH branch renaming support has landed: https://github.blog/changelog/2021-01-19-support-for-renaming-an-existing-branch

[keszybz]

I did the renaming in https://github.com/systemd/zram-generator. It is indeed painless. I had one PR, and the PR was automatically updated. In my local repo, git pull fails cleanly, but git branch --set-upstream-to origin/main was enough to restore functionality. Looks like this is good to go.

[keszybz]

CI uses the branch name though. I'm pretty sure that at least ubuntuautopkg tests have "branch=master" included in the CI request urls. We'll need to update those. @xnox?

What about centos ci, does it hardcode the branch name? @mrc0mmand

[mrc0mmand]

What about centos ci, does it hardcode the branch name? @mrc0mmand

It does, but the switch should be quick and painless.

[keszybz]

OK. So it sounds all easy, except that we need to coordinate the update of ubuntuautopkg tests and centos ci. @mrc0mmand will update the latter. Do we have someone who can sign up to update ubuntuautopkg tests?

[poettering]

btw, I am happy if the rename happens any time, from my side no further discussion or delays needed. just do it.

maybe @mrc0mmand should do the switch when it's best for him, so that he can sync it up with the CI update.

[mrc0mmand]

btw, I am happy if the rename happens any time, from my side no further discussion or delays needed. just do it.

maybe @mrc0mmand should do the switch when it's best for him, so that he can sync it up with the CI update.

I could introduce a temporary workaround, that would check which branch is the main one and use it, thus make it compatible with both master and main. If something similar was implemented in the Ubuntu CI as well, we could do the renaming asynchronously without breaking anything.

[mbiebl]

I'd just do the switch and fix-up the fall-out.
I'm around regarding the Debian side of things.

[keszybz]

Done.

Instruction from github for local clones:

git branch -m master main
git fetch origin
git branch -u origin/main main

Please report any CI fallout in this ticket.

[xnox]

Instead of deleting master branch, one can push a soft-reference to make an alias to main => if that is causing any temporary issues anywhere.

[mbiebl]

@keszybz can you update https://github.com/systemd/systemd-stable accordingly?

[mbiebl]

https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/extra/checkout-upstream#L85 might need an update

[evverx]

https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/extra/checkout-upstream#L85 might need an update

To judge from https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-upstream-systemd-ci-systemd-ci/bionic/amd64/s/systemd-upstream/20210121_135821_3d77c@/log.gz where the script failed with

From https://github.com/systemd/systemd
 * [new ref]               refs/pull/18335/head -> pr
Switched to branch 'pr'
fatal: Needed a single revision
invalid upstream 'master'
debian/rules:210: recipe for target 'override_dh_auto_clean' failed
make[1]: *** [override_dh_auto_clean] Error 1
make[1]: Leaving directory '/tmp/autopkgtest.lBPZsd/build.v8U/systemd'
debian/rules:315: recipe for target 'clean' failed
make: *** [clean] Error 2

, it does

[mbiebl]

https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/extra/checkout-upstream#L85 might need an update

Fixed

[evverx]

Thank you! I'll force-push #18335 to trigger Ubuntu CI to make sure it works.

[mrc0mmand]

@mrc0mmand could you point Semaphore CI to main?

Done, thanks for the hint!

I'm not sure I have access to the settings there.

You should have an admin access there.

[evverx]

Looks like I should have logged in properly :-) I can't seem to change the badge at https://the-real-systemd.semaphoreci.com/projects/systemd/settings/badge (which I think should be added to README eventually) though.

[mrc0mmand]

Looks like I should have logged in properly :-) I can't seem to change the badge at https://the-real-systemd.semaphoreci.com/projects/systemd/settings/badge (which I think should be added to README eventually) though.

The badge should be already there 2e445f4 :-)

[evverx]

It's there but it shows the status of the master branch as far as I can tell: https://the-real-systemd.semaphoreci.com/badges/systemd/branches/master.svg

[mrc0mmand]

It's there but it shows the status of the master branch as far as I can tell: https://the-real-systemd.semaphoreci.com/badges/systemd/branches/master.svg

Ugh, you're right, I'm blind :-)

[![Build Status](https://the-real-systemd.semaphoreci.com/badges/systemd/branches/main.svg?style=shields)](https://the-real-systemd.semaphoreci.com/projects/systemd)

should do the trick. Will open a PR once I'll get my fork migrated as well.

[keszybz]

@keszybz can you update https://github.com/systemd/systemd-stable accordingly?

Done.

[mbiebl]

Instruction from github for local clones:

git branch -m master main
git fetch origin
git branch -u origin/main main

Hm, ...

$ git gc
fatal: bad object refs/remotes/origin/HEAD
fatal: failed to run repack
$ cat .git/refs/remotes/origin/HEAD 
ref: refs/remotes/origin/master

I wonder what I did wrong...

[keszybz]

$ git gc
fatal: bad object refs/remotes/origin/HEAD
fatal: failed to run repack
$ cat .git/refs/remotes/origin/HEAD 
ref: refs/remotes/origin/master

I have the same content in .git/refs/remotes/origin/HEAD, but it doesn't seem to cause any issues (git-2.29.2-3.fc33.x86_64). What version do you have?

[mbiebl]

$ git version
git version 2.30.0

I semi-regularly run "mr run git gc", where I noticed this error.
Are you saying that with 2.29.2 you don't get any error when running "git gc" ?

[keszybz]

Are you saying that with 2.29.2 you don't get any error when running "git gc" ?

Yes.

Also, no error with git-2.30.0-1.fc33.x86_64.

[mbiebl]

Also, no error with git-2.30.0-1.fc33.x86_64.

hm, weird. anyway, will fix the file manually.