mirror/oot
1
0
Fork 0
mirror of https://github.com/zeldaret/oot.git synced 2024-11-10 19:20:13 +00:00
Code Issues Projects Releases Wiki Activity

Rename master to main (#1536)

Browse source 
* Jenkinsfile master -> main

* Missed some instances of master
This commit is contained in:
Derek Hensley 2023-09-22 08:40:19 -07:00 committed by GitHub
parent d7f6961918
commit dc010abf7a
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
4 changed files with 11 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
Jenkinsfile vendored
View file

@ -17,7 +17,7 @@ pipeline {
}
stage('Build (qemu-irix)') {
when {
branch 'master'
branch 'main'
}
steps {
sh 'ORIG_COMPILER=1 make -j'
@ -26,7 +26,7 @@ pipeline {
stage('Build') {
when {
not {
branch 'master'
branch 'main'
}
}
steps {
@ -35,7 +35,7 @@ pipeline {
}
stage('Report Progress') {
when {
branch 'master'
branch 'main'
}
steps {
sh 'mkdir reports'
@ -47,7 +47,7 @@ pipeline {
}
stage('Update Progress') {
when {
branch 'master'
branch 'main'
}
agent {
label 'zeldaret_website'

4
README.md
View file

@ -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/OOT/job/master
[jenkins-badge]: https://img.shields.io/jenkins/build?jobUrl=https%3A%2F%2Fjenkins.deco.mp%2Fjob%2FOOT%2Fjob%2Fmaster
[jenkins]: https://jenkins.deco.mp/job/OOT/job/main
[jenkins-badge]: https://img.shields.io/jenkins/build?jobUrl=https%3A%2F%2Fjenkins.deco.mp%2Fjob%2FOOT%2Fjob%2Fmain
[progress]: https://zelda64.dev/games/oot
[progress-badge]: https://img.shields.io/endpoint?url=https://zelda64.dev/assets/csv/progress-oot-shield.json

8
docs/tutorial/merging.md
View file

@ -61,9 +61,9 @@ If you can't match a function even with everyone's, don't worry overlong about i
Run the formatting script `format.py`, to format the C files in the standard way we use.
### 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
@ -81,7 +81,7 @@ and so on, although these four tend to cover most cases. Feel free to add a comm
Pull requests may be reviewed by anyone (who knows enough about the conventions of the project), but all are usually reviewed by Fig and Roman.
To implement suggestions made in reviews, it is generally easier to be consistent if you push more commits from your local branch. It is 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 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 actor.
@ -94,4 +94,4 @@ It's helpful to use the labels on Trello.
- Matched for when it is totally decompiled and matching
- Documented if at least everything is named and odd code is commented. We'll likely wipe these and start over when proper documentation begins.
We now have a PR label on the Trello that you can use to indicate your actor is in a PR. When the actor is committed to master, you can move the actor into the `Decompiled Files (Overlays)` column: it goes at the top if there is a non-matching, and below if not.
We now have a PR label on the Trello that you can use to indicate your actor is in a PR. When the actor is committed to main, you can move the actor into the `Decompiled Files (Overlays)` column: it goes at the top if there is a non-matching, and below if not.

2
docs/tutorial/pre-decomp.md
View file

@ -10,7 +10,7 @@ This is covered on the main page of the repository.
First, make a GitHub fork of the repository, then clone it into a git-enabled local folder.
Once you have decided on an actor, you should make a new git branch to work on: your master branch is meant to stay level with the main repository. Name it something sensible: my `EnFirefly` branch is called "en_firefly", for example, but you may prefer to use a more descriptive name: "Dark_Link" is rather more suggestive than "en_torch2", for example. You work on the branch, commit changes, and periodically push them to GitHub, if only for backup purposes.
Once you have decided on an actor, you should make a new git branch to work on: your main branch is meant to stay level with the main repository. Name it something sensible: my `EnFirefly` branch is called "en_firefly", for example, but you may prefer to use a more descriptive name: "Dark_Link" is rather more suggestive than "en_torch2", for example. You work on the branch, commit changes, and periodically push them to GitHub, if only for backup purposes.
Once you have finished an actor, you submit a pull request for other people to check your work complies with the project's conventions, and once it is deemed satisfactory, it will be merged in to the main repository.