Rename things from master to main (#581)

Signed-off-by: Henry Davidge <[email protected]>
Co-authored-by: Henry Davidge <[email protected]>

.circleci/config.yml

@@ -331,7 +331,7 @@ workflows:
           filters:
             branches:
               only:
-                - master
+                - main
     jobs:
       - check-docs
       - spark-3-4-tests

.github/workflows/scala-dependency.yml

@@ -3,7 +3,7 @@ name: Update Dependency Graph
 on:
   push:
     branches:
-      - master
+      - main
 
 jobs:
   update-graph:

CONTRIBUTING.md

@@ -19,7 +19,7 @@ Code review takes place in GitHub pull requests. See [this article](https://help
 Once you open a pull request, project maintainers will review your code and respond to your pull request with any feedback they might have. The process at this point is as follows:
 
 1. An Approval is required from one of the project maintainers.
-2. Your change will be merged into the project's `master` branch
+2. Your change will be merged into the project's `main` branch
 
 ### Developer Certification of Origin (DCO)
 

GIT-PROCESS.md

@@ -35,28 +35,28 @@ git fetch upstream
 git branch -va
 ```
 
-Now, checkout your own master branch and merge the upstream repo's master branch:
+Now, checkout your own main branch and merge the upstream repo's main branch:
 
 ```shell
-# Checkout your master branch and merge upstream
-git checkout master
-git merge upstream/master
+# Checkout your main branch and merge upstream
+git checkout main
+git merge upstream/main
 ```
 
-If there are no unique commits on the local master branch, git will simply perform a fast-forward. However, if you have been making changes on master (in the vast majority of cases you probably shouldn't be - [see the next section](#doing-your-work), you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.
+If there are no unique commits on the local main branch, git will simply perform a fast-forward. However, if you have been making changes on main (in the vast majority of cases you probably shouldn't be - [see the next section](#doing-your-work), you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.
 
-Now, your local master branch is up-to-date with everything modified upstream.
+Now, your local main branch is up-to-date with everything modified upstream.
 
 ## Doing Your Work
 
 ### Create a Branch
-Whenever you begin work on a new feature or bugfix, it's important that you create a new branch. Not only is it proper git workflow, but it also keeps your changes organized and separated from the master branch so that you can easily submit and manage multiple pull requests for every task you complete.
+Whenever you begin work on a new feature or bugfix, it's important that you create a new branch. Not only is it proper git workflow, but it also keeps your changes organized and separated from the main branch so that you can easily submit and manage multiple pull requests for every task you complete.
 
 To create a new branch and start working on it:
 
 ```shell
-# Checkout the master branch - you want your new branch to come from master
-git checkout master
+# Checkout the main branch - you want your new branch to come from main
+git checkout main
 
 # Create a new branch named newfeature (give your branch its own simple informative name)
 git branch newfeature
@@ -73,25 +73,25 @@ Now, go to town hacking away and making whatever changes you want to.
 
 Prior to submitting your pull request, you might want to do a few things to clean up your branch and make it as simple as possible for the original repo's maintainer to test, accept, and merge your work.
 
-If any commits have been made to the upstream master branch, you should rebase your development branch so that merging it will be a simple fast-forward that won't require any conflict resolution work.
+If any commits have been made to the upstream main branch, you should rebase your development branch so that merging it will be a simple fast-forward that won't require any conflict resolution work.
 
 ```shell
-# Fetch upstream master and merge with your repo's master branch
+# Fetch upstream main and merge with your repo's main branch
 git fetch upstream
-git checkout master
-git merge upstream/master
+git checkout main
+git merge upstream/main
 
 # If there were any new commits, rebase your development branch
 git checkout newfeature
-git rebase master
+git rebase main
 ```
 
 Now, it may be desirable to squash some of your smaller commits down into a small number of larger more cohesive commits. You can do this with an interactive rebase:
 
 ```shell
 # Rebase all commits on your development branch
 git checkout 
-git rebase -i master
+git rebase -i main
 ```
 
 This will open up a text editor where you can specify which commits to squash.
@@ -131,16 +131,16 @@ To do the merge manually, you'll need to checkout the target branch in the sourc
 
 ```shell
 # Checkout the branch you're merging to in the target repo
-git checkout master
+git checkout main
 
 # Pull the development branch from the fork repo where the pull request development was done.
 git pull https://github.com/forkuser/forkedrepo.git newfeature
 
 # Merge the development branch
 git merge newfeature
 
-# Push master with the new feature merged into it
-git push origin master
+# Push main with the new feature merged into it
+git push origin main
 ```
 
 Now that you're done with the development branch, you're free to delete it.

README.md

@@ -23,7 +23,7 @@ Status](https://readthedocs.org/projects/glow/badge/?version=latest)](https://gl
 [![Docker Hub Pulls](https://raster.shields.io/docker/pulls/projectglow/databricks-glow.svg)](https://hub.docker.com/r/projectglow/databricks-glow)
 [![PyPi](https://img.shields.io/pypi/v/glow.py.svg)](https://pypi.org/project/glow.py/)
 [![Maven Central](https://img.shields.io/maven-central/v/io.projectglow/glow-spark3_2.12.svg)](https://mvnrepository.com/artifact/io.projectglow)
-[![Coverage Status](https://codecov.io/gh/projectglow/glow/branch/master/graph/badge.svg)](https://codecov.io/gh/projectglow/glow)
+[![Coverage Status](https://codecov.io/gh/projectglow/glow/branch/main/graph/badge.svg)](https://codecov.io/gh/projectglow/glow)
 [![Conda Version](https://img.shields.io/conda/vn/conda-forge/glow.svg)](https://anaconda.org/conda-forge/glow)
 [![DOI](https://zenodo.org/badge/212904926.svg)](https://zenodo.org/badge/latestdoi/212904926)
 

docs/dev/run-nb-test.py

@@ -54,7 +54,7 @@ def run_cli_cmd(cli_profile, api, args):
 @click.option('--workflow-definition', default='docs/dev/multitask-integration-test-config.json', help='path to json configuration')
 @click.option('--repos-path', default='/Repos/staging', help='Path in Databricks workspace for running integration test')
 @click.option('--repos-url', default='https://github.com/projectglow/glow', help='URL for your fork of glow')
-@click.option('--branch', default='master', help='Update to your branch that you are testing on')
+@click.option('--branch', default='main', help='Update to your branch that you are testing on')
 @click.option('--dockerhub_password', default='DEFAULT', help='Password for projectglow dockerhub account')
 def main(cli_profile, workflow_definition, repos_path, repos_url, branch, dockerhub_password):
     click.echo("cli_profile = " + cli_profile)

docs/source/contributing.rst

@@ -57,7 +57,7 @@ And run this python script (swapping the html file out for your own).
    python3 docs/dev/gen-nb-src.py --html docs/source/_static/notebooks/tertiary/pipe-transformer-vep.html
 
 The Glow workflow is tested in a nightly integration test in Databricks.
-If you add notebooks or rename them, please also edit the workflow definition json located in `docs/dev/ <https://github.com/projectglow/glow/blob/master/docs/dev>`_.
+If you add notebooks or rename them, please also edit the workflow definition json located in `docs/dev/ <https://github.com/projectglow/glow/blob/main/docs/dev>`_.
 
 .. _improve-documentation: