Rename the Primary Branch from Master to Main

[aminjam]

Enter an issue title

Rename the Primary Branch from master to main

Summary

In support of Proposal to Rename the Primary Branch on all Cloud Foundry repos, we would like to move away from Master branch to Main.

Here is an example of a script that helps with the migration or we can use Git 2.28 for an easier workflow

Questions

• Can this change break old releases? We've used master branch in gitmodules, so will older tags still work?
• Most pipelines and go modules that pull diego-release components will break. What sort of communication should we have for this change? (e.g. https://pkg.go.dev/code.cloudfoundry.org/bytefmt?tab=importedby)
• Update all of the docs that were pointing to the master branch

Diego repo

All of the Diego repo's in cloudfoundry and cloudfoundry-incubator

• https://github.com/cloudfoundry/diego-release
• https://github.com/cloudfoundry/archiver
• https://github.com/cloudfoundry/auction
• https://github.com/cloudfoundry/auctioneer
• https://github.com/cloudfoundry/bbs
• https://github.com/cloudfoundry/benchmarkbbs
• https://github.com/cloudfoundry/bytefmt
• https://github.com/cloudfoundry/cacheddownloader
• https://github.com/cloudfoundry/certsplitter
• https://github.com/cloudfoundry/cfdot
• https://github.com/cloudfoundry/clock
• https://github.com/cloudfoundry/consuladapter
• https://github.com/cloudfoundry/debugserver
• https://github.com/cloudfoundry/diego-dockerfiles
• https://github.com/cloudfoundry/diego-logging-client
• https://github.com/cloudfoundry/diego-upgrade-stability-tests
• https://github.com/cloudfoundry/dockerdriver
• https://github.com/cloudfoundry/durationjson
• https://github.com/cloudfoundry/ecrhelper
• https://github.com/cloudfoundry/eventhub
• https://github.com/cloudfoundry/executor
• https://github.com/cloudfoundry/fileserver
• https://github.com/cloudfoundry/healthcheck
• https://github.com/cloudfoundry/inigo
• https://github.com/cloudfoundry/localdriver
• https://github.com/cloudfoundry/localip
• https://github.com/cloudfoundry/locket
• https://github.com/cloudfoundry/operationq
• https://github.com/cloudfoundry/rep
• https://github.com/cloudfoundry/route-emitter
• https://github.com/cloudfoundry/systemcerts
• https://github.com/cloudfoundry/tlsconfig
• https://github.com/cloudfoundry/vizzini
• https://github.com/cloudfoundry/volman
• https://github.com/cloudfoundry/workpool

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.

The labels on this github issue will be updated when the story is started.

[aminjam]

There seems to be more tooling coming from Github that will help with the migration.

go.mod imports will break. I found the following documentation that suggests using branches in go.mod is not a recommended pattern. Since CF mailing list had already proposed this change, we don't need any other communication for this change.

Given the number of repositories we have, I propose we wait until the new tooling is introduced in Github.

[jvshahid]

Can this change break old releases? We've used master branch in gitmodules, so will older tags still work?

I don't think it will break old tags. From https://man7.org/linux/man-pages/man7/gitsubmodules.7.html:

The .gitmodules file inside the superproject [...] If the submodule has never
been initialized, this is the only place where submodule configuration is
found. It serves as the last fallback to specify where to obtain the
submodule from.

For existing clones of diego-release, git should use the local configuration and not pay attention to .gitmodules anymore. A Clone of an old diego-release should not pose a problem either. I believe if git cannot find the branch name given in .gitmodules, it uses the current HEAD or default branch name.

I used the following script with git version 2.28.0 to test the behavior when cloning and the branch of the submodule does not exist:

Expand code

submodule_path=""
initialize_submodule() {
    local dir=$(mktemp -d submoduleXXXX)
    pushd $dir
      git init
      touch empty
      git add empty
      git commit -m 'Touched empty'
      submodule_path=$(pwd)

      if [ "x$REMOTE" != "x" ]; then
          submodule_path=${REMOTE}-submodule
          git push --force ${submodule_path} master
      fi

      echo "Created submodule in ${submodule_path}"
    popd
}

superproject_name=""
superproject_path=""
initialize_superproject() {
    if [ $# -ne 1 ]; then
        echo "Usage: $0 submodule-name or submodule-path"
        exit 1
    fi

    local submodule_path=$1
    submodule_name=$(basename ${submodule_path})

    local dir=$(mktemp -d superprojectXXXX)
    pushd $dir
      git init
      git submodule add ${submodule_path} ./src/${submodule_name}
      git add src/${submodule_name}
      git commit -m 'Add submodule'
      superproject_path=$(pwd)

      if [ "x$REMOTE" != "x" ]; then
          superproject_path=${REMOTE}-superproject
          git push --force ${superproject_path} master
      fi

      echo "Created superproject in ${superproject_path}"
    popd
}

clone() {
    if [ $# -lt 2 ]; then
        echo "Usage: $0 src dst [git-clone-args]"
        exit 1
    fi

    local src=$1
    local dst=$2
    shift 2

    git clone $src $dst "$@"
}

change_submodule_branch_name() {
    local dir=$(mktemp -d cloned_submoduleXXXX)
    clone ${submodule_path} ${dir}
    pushd $dir
      git branch -m master main
      git push origin main
      # TODO: are we deleting the old master branch?
      if [ "x$REMOTE" == x ]; then
          pushd ${submodule_path}
            # we can delete a checked out branch
            git checkout main
          popd
      fi
      git push origin :master
    popd
}

test() {
    local dir=$(mktemp -d cloned_projectXXXXX)
    change_submodule_branch_name
    clone ${superproject_path} ${dir} --recurse-submodules
}

initialize_submodule
initialize_superproject ${submodule_path}

test