master to main rename (#1379)

* master -> main

* Missed some instances of master

Jenkinsfile

@@ -84,7 +84,7 @@ pipeline {
         }
         stage('Report Progress') {
             when {
-                branch 'master'
+                branch 'main'
             }
             steps {
                 sh 'mkdir reports'
@@ -96,7 +96,7 @@ pipeline {
         }
         stage('Update Progress') {
             when {
-                branch 'master'
+                branch 'main'
             }
             agent{
                 label 'zeldaret_website'

README.md

@@ -2,8 +2,8 @@
 
 [![Build Status][jenkins-badge]][jenkins] [![Decompilation Progress][progress-badge]][progress] [![Contributors][contributors-badge]][contributors] [![Discord Channel][discord-badge]][discord]
 
-[jenkins]: https://jenkins.deco.mp/job/MM/job/master
+[jenkins]: https://jenkins.deco.mp/job/MM/job/main
-[jenkins-badge]: https://img.shields.io/jenkins/build?jobUrl=https%3A%2F%2Fjenkins.deco.mp%2Fjob%2FMM%2Fjob%2Fmaster
+[jenkins-badge]: https://img.shields.io/jenkins/build?jobUrl=https%3A%2F%2Fjenkins.deco.mp%2Fjob%2FMM%2Fjob%2Fmain
 
 [progress]: https://zelda64.dev/games/mm
 [progress-badge]: https://img.shields.io/endpoint?url=https://zelda64.dev/assets/csv/progress-mm-shield.json

docs/CONTRIBUTING.md

@@ -4,19 +4,19 @@ Thanks for helping us reverse engineer *The Legend of Zelda: Majora's Mask* for
 All contributions are welcome. This is a group effort, and even small contributions can make a difference. Some tasks also don't require much knowledge to get started.
 
 This document is meant to be a set of tips and guidelines for contributing to the project.
-For general information about the project, see [our readme](https://github.com/zeldaret/mm/blob/master/README.md).
+For general information about the project, see [our readme](https://github.com/zeldaret/mm/blob/main/README.md).
 
 Most discussions happen on our [Discord Server](https://discord.zelda64.dev) where you are welcome to ask if you need help getting started, or if you have any questions regarding this project and other decompilation projects.
 
 ## Useful Links
 
-- [Installation guide](https://github.com/zeldaret/mm/blob/master/README.md#installation) - Instructions for getting this repository set up and built on your machine.
+- [Installation guide](https://github.com/zeldaret/mm/blob/main/README.md#installation) - Instructions for getting this repository set up and built on your machine.
 - [Style Guide](STYLE.md) - Description of the project style that we ask contributors to adhere to.
 - [Code Review Guidelines](REVIEWING.md) - These are the guidelines that reviewers will be using when reviewing your code. Good to be familiar with these before submitting your code.
 
 - [Zelda 64 Reverse Engineering Website](https://zelda64.dev/games/mm) - Our homepage, with FAQ and progress graph :chart_with_upwards_trend:.
 - [MM decomp tutorial](tutorial/contents.md) Detailed tutorial for learning in general how decomp works and how to decompile a small, simple file.
-- [Introduction to OOT decomp](https://github.com/zeldaret/oot/blob/master/docs/tutorial/contents.md) - The tutorial the MM one was based on. For OOT, but largely applicable to MM as well. Covers slightly different topics, including how to get your data OK with `vbindiff`.
+- [Introduction to OOT decomp](https://github.com/zeldaret/oot/blob/main/docs/tutorial/contents.md) - The tutorial the MM one was based on. For OOT, but largely applicable to MM as well. Covers slightly different topics, including how to get your data OK with `vbindiff`.
 - The `#resources` channel on the Discord contains many more links on specific details of decompiling IDO MIPS code.
 
 ## Getting Started
@@ -37,7 +37,7 @@ This project only uses *publicly available code*.
 
 ### Environment Setup
 
-Get started by following the [installation guide in the readme](https://github.com/zeldaret/mm/blob/master/README.md#installation).
+Get started by following the [installation guide in the readme](https://github.com/zeldaret/mm/blob/main/README.md#installation).
 You should be able to build a matching ROM before you start making any changes.
 
 ### First Contribution
@@ -142,8 +142,8 @@ Project leads are responsible for ensuring that these conventions are followed.
 
 ### Some git notes
 
-- You should work on a branch on your fork separate from your copy of master: it is always useful to have a clean master branch around if you need to fix something.
+- You should work on a branch on your fork separate from your copy of main: it is always useful to have a clean main branch around if you need to fix something.
-- When a PR is merged into master, it may conflict with your work. While your branch is private (in particular, not used for a PR), you can rebase, but when your branch is public/used for a PR always merge master instead of rebasing: it makes it much easier for people to understand what you changed since the last review.
+- When a PR is merged into main, it may conflict with your work. While your branch is private (in particular, not used for a PR), you can rebase, but when your branch is public/used for a PR always merge main instead of rebasing: it makes it much easier for people to understand what you changed since the last review.
 - We squash commits when merging, so your commit history does not have to be completely spotless.
 
 Throughout the PR process, you (the author) should update the rows on the appropriate Google Sheets with the appropriate information as the decompilation process progresses.

docs/REVIEWING.md

@@ -5,7 +5,7 @@ We encourage all contributors to participate in code review: this is your codeba
 Every review submitted helps us keep code quality high and code merged in more quickly.
 
 This document is meant to be a set of tips and guidelines for reviewers of pull requests to the project.
-For general information about the project, see [our readme](https://github.com/zeldaret/mm/blob/master/README.md).
+For general information about the project, see [our readme](https://github.com/zeldaret/mm/blob/main/README.md).
 
 Most discussions happen on our [Discord Server](https://discord.zelda64.dev) where you are welcome to ask if you need help getting started, or if you have any questions regarding this project and other decompilation projects.
 

docs/tutorial/beginning_decomp.md

@@ -175,7 +175,7 @@ The Init function sets up the various components of the actor when it is first l
 
 The first stage of decompilation is done by a program called mips_to_c, often referred to as mips2c, which constructs a C interpretation of the assembly code based on reading it very literally. This means that considerable cleanup will be required to turn it into something that firstly compiles at all, and secondly looks like a human wrote it, let alone a Zelda developer from the late '90s.
 
-The web version of mips2c can be found [here](https://simonsoftware.se/other/mips_to_c.py). This was [covered in the OoT tutorial](https://github.com/zeldaret/oot/blob/master/docs/tutorial/beginning_decomp.md). We shall instead use the repository. Clone [the mips_to_c repository](https://github.com/matt-kempster/mips_to_c) into a separate directory (we will assume on the same level as the `mm/` directory). Since it's Python, we don't have to do any compilation or anything in the mips_to_c directory.
+The web version of mips2c can be found [here](https://simonsoftware.se/other/mips_to_c.py). This was [covered in the OoT tutorial](https://github.com/zeldaret/oot/blob/main/docs/tutorial/beginning_decomp.md). We shall instead use the repository. Clone [the mips_to_c repository](https://github.com/matt-kempster/mips_to_c) into a separate directory (we will assume on the same level as the `mm/` directory). Since it's Python, we don't have to do any compilation or anything in the mips_to_c directory.
 
 Since the actor depends on the rest of the codebase, we can't expect to get much intelligible out of mips2c without giving it some context. We make this using a Python script in the `tools` directory called `m2ctx.py`, so run
 
@@ -686,7 +686,7 @@ as our first guess. This doesn't look unreasonable... the question is, does it m
 
 Once preliminary cleanup and struct filling is done, most time spent matching functions is done by comparing the original code with the code you have compiled. This is aided by a program called `diff.py`.
 
-In order to use `diff.py` with the symbol names, we need a copy of the code to compare against. In MM this is done as part of `make init`, and you can regenerate the `expected` directory (which is simply a known-good copy of `build` directory) by running `make diff-init`, which will check for an OK ROM and copy the build directory over. (Of course you need an OK ROM to do this; worst-case, you can checkout master and do a complete rebuild to get it). (You need to remake `expected` if you want to diff a function you have renamed: `diff.py` looks in the mapfiles for the function name, which won't work if the name has changed!)
+In order to use `diff.py` with the symbol names, we need a copy of the code to compare against. In MM this is done as part of `make init`, and you can regenerate the `expected` directory (which is simply a known-good copy of `build` directory) by running `make diff-init`, which will check for an OK ROM and copy the build directory over. (Of course you need an OK ROM to do this; worst-case, you can checkout main and do a complete rebuild to get it). (You need to remake `expected` if you want to diff a function you have renamed: `diff.py` looks in the mapfiles for the function name, which won't work if the name has changed!)
 
 Now, we run diff on the function name: in the main directory,
 

docs/tutorial/data.md

@@ -27,7 +27,7 @@ Both approaches have their advantages and disadvantages.
 
 ## Data first
 
-This way is good for smaller actors with little data. The OoT tutorial [covers this in plenty of detail](https://github.com/zeldaret/oot/blob/master/docs/tutorial/data.md), and the process in MM is essentially identical, so we won't go over it here.
+This way is good for smaller actors with little data. The OoT tutorial [covers this in plenty of detail](https://github.com/zeldaret/oot/blob/main/docs/tutorial/data.md), and the process in MM is essentially identical, so we won't go over it here.
 
 ## Extern and data last
 

docs/tutorial/diff_and_permuter.md

@@ -2,7 +2,7 @@
 
 This document is intended as a step-by-step demonstration of matching a reasonably complex function using the diff script `diff.py` and the decomp permuter, both included in the repo. For general information on both see [the tools documentation](../tools.md).
 
-Until such time as someone finds a suitable function, you can look at the OoT tutorial: [here for diff.py](https://github.com/zeldaret/oot/blob/master/docs/tutorial/beginning_decomp.md#diff) and [here for the permuter](https://github.com/zeldaret/oot/blob/master/docs/tutorial/other_functions.md#the-permuter).
+Until such time as someone finds a suitable function, you can look at the OoT tutorial: [here for diff.py](https://github.com/zeldaret/oot/blob/main/docs/tutorial/beginning_decomp.md#diff) and [here for the permuter](https://github.com/zeldaret/oot/blob/main/docs/tutorial/other_functions.md#the-permuter).
 
 
 <!-- 

docs/tutorial/draw_functions.md

@@ -325,6 +325,6 @@ void ObjTree_Draw(Actor* thisx, PlayState* play) {
 
 TODO: find some examples for this one.
 
-For even more examples, you can consult [the OoT tutorial](https://github.com/zeldaret/oot/blob/master/docs/tutorial/draw_functions.md)
+For even more examples, you can consult [the OoT tutorial](https://github.com/zeldaret/oot/blob/main/docs/tutorial/draw_functions.md)
 
 Next: [Data](data.md)

docs/tutorial/intro_to_git.md

@@ -14,7 +14,7 @@ Remote
 ---o---o---o---o
 
 Local
-             master
+             main
                v
 ---o---o---o---o
             \
@@ -23,7 +23,7 @@ Local
                  A
 ```
 
-Each `o` is a commit. The lines show the commit that each commit was based on: we can see in the local there is one commit with two commits based on it. The local has two branches, `master` and `A`, and they currently both point to the commits furthest along their respective chains.
+Each `o` is a commit. The lines show the commit that each commit was based on: we can see in the local there is one commit with two commits based on it. The local has two branches, `main` and `A`, and they currently both point to the commits furthest along their respective chains.
 
 Throughout this guide, stuff in `SCREAMING_SNAKE_CASE` represents fields for you to fill in with the appropriate text, e.g. FILE should be replaced with a particular filename.
 
@@ -48,7 +48,7 @@ git init
 
 The repository is considered to have the same name as the directory in which it lives.
 
-The default branch is set to be called `master`. If you want to call it something else, do
+The default branch is set to be called `main`. If you want to call it something else, do
 
 ```bash
 git init -b DEFAULT_BRANCH_NAME
@@ -112,7 +112,7 @@ git add git@github.com:yourgithubaccount/mm.git
 
 ## Managing branches
 
-You should always work on a branch, to retain a clean copy of the repository that you know works on the master/main branch, and to enable you to switch between unrelated work easily.
+You should always work on a branch, to retain a clean copy of the repository that you know works on the main/main branch, and to enable you to switch between unrelated work easily.
 
 To list the branches you currently have:
 

docs/tutorial/merging.md

@@ -68,9 +68,9 @@ Run the formatting script `format.py`, to format the C files in the standard way
 
 **N.B.** this is now essential: the CI will fail immediately if it detects files that change when formatted.
 
-### Merge master
+### Merge main
 
-To make sure the PR builds correctly with the current master, you need to merge `upstream/master` before you make the PR. This tends to break things, that you have to fix to get it to compile correctly again.
+To make sure the PR builds correctly with the current main, you need to merge `upstream/main` before you make the PR. This tends to break things, that you have to fix to get it to compile correctly again.
 
 ## Pull Requests
 
@@ -89,6 +89,6 @@ Please also update the status of the file on Trello/the spreadsheet.
 
 Pull requests may be reviewed by anyone (who knows enough about the conventions of the project), and all must be reviewed and approved by two leads and one extra contributor.
 
-To implement suggestions made in reviews, it is generally easier to be consistent if you push more commits from your local branch. It is also quite possible that in the meantime some other PR has gone in, and git will ask you to merge master before you add more commits. This is normally fairly painless, although often you have to resolve merge conflicts. If in doubt, backup your work before doing anything, and ask in Discord before doing anything drastic, or if you don't understand what git is telling you.
+To implement suggestions made in reviews, it is generally easier to be consistent if you push more commits from your local branch. It is also quite possible that in the meantime some other PR has gone in, and git will ask you to merge main before you add more commits. This is normally fairly painless, although often you have to resolve merge conflicts. If in doubt, backup your work before doing anything, and ask in Discord before doing anything drastic, or if you don't understand what git is telling you.
 
 There is no need to wait for your PR to be approved and committed before working on your next file.

docs/tutorial/object_decomp.md

@@ -62,7 +62,7 @@ You'll want to name everything that exists in the XML, but it helps to break it
 
 You'll notice that we didn't mention vertices in this list. This is because, for the most part, vertices are not used outside the object itself, and so are not required to have names. However, some actors have code that manipulates or otherwise interacts with vertices; in these cases, the vertices should be added to the XML and named.
 
-Current naming practice is to name each item in the xml using camelCase as usual, with the `g` prefix (for "global"), and the type of data last (`Skel`, `Anim`, `DL`, `Tex`, `TLUT`, `Vtx`, `TexAnim`, etc.), while output texture files are named in `snake_case`. TLUTs (texture look-up tables) should always have their output file end in `tlut`. For more info on which suffixes to use, check out the [ZAPD documentation on extraction XML](https://github.com/zeldaret/mm/blob/master/tools/ZAPD/docs/zapd_extraction_xml_reference.md).
+Current naming practice is to name each item in the xml using camelCase as usual, with the `g` prefix (for "global"), and the type of data last (`Skel`, `Anim`, `DL`, `Tex`, `TLUT`, `Vtx`, `TexAnim`, etc.), while output texture files are named in `snake_case`. TLUTs (texture look-up tables) should always have their output file end in `tlut`. For more info on which suffixes to use, check out the [ZAPD documentation on extraction XML](https://github.com/zeldaret/mm/blob/main/tools/ZAPD/docs/zapd_extraction_xml_reference.md).
 
 ### Textures
 
@@ -156,6 +156,6 @@ The reason this happens is because ZAPD couldn't determine the TLUT for the text
 
 ### Understanding texture animations
 
-Texture animations are new to Majora's Mask, and they can be pretty tricky to understand. Luckily, there's some extensive documentation on how they're structured [here](https://github.com/zeldaret/mm/blob/master/tools/ZAPD/ZAPD/ZTextureAnimation.cpp). One useful thing to remember is that empty texture animations take the form of `00 00 00 06 00 00 00 00`. The process that automatically generated all the object XMLs sometimes failed to recognize this as an empty texture animation, so it puts it in various blobs or fails to account for it at all.
+Texture animations are new to Majora's Mask, and they can be pretty tricky to understand. Luckily, there's some extensive documentation on how they're structured [here](https://github.com/zeldaret/mm/blob/main/tools/ZAPD/ZAPD/ZTextureAnimation.cpp). One useful thing to remember is that empty texture animations take the form of `00 00 00 06 00 00 00 00`. The process that automatically generated all the object XMLs sometimes failed to recognize this as an empty texture animation, so it puts it in various blobs or fails to account for it at all.
 
 Next: [The merging process](merging.md)