mirrors/brew
1
0
Fork 0
mirror of https://github.com/Homebrew/brew.git synced 2025-07-14 16:09:03 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs: homebrew-core's default branch is now main

Browse Source 
Adjust documentation accordingly.
This commit is contained in:
Mike McQuaid 2025-06-25 08:49:58 +01:00
parent 36ae1ee429
commit e11952a2e0
No known key found for this signature in database
3 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/Formula-Cookbook.md
View File

@ -1298,9 +1298,9 @@ Packages requiring BLAS/LAPACK linear algebra interfaces should link to [OpenBLA
## How to start over (reset to upstream)
Have you created a real mess in Git which stops you from creating a commit you want to submit to us? You might want to consider starting again from scratch. Your changes to the Homebrew `master` branch can be reset by running:
Have you created a real mess in Git which stops you from creating a commit you want to submit to us? You might want to consider starting again from scratch. Your changes to the Homebrew `main` branch can be reset by running:
```sh
git checkout -f master
git checkout -f main
git reset --hard origin/HEAD
```

12
docs/Homebrew-homebrew-core-Maintainer-Guide.md
View File

@ -33,7 +33,7 @@ PRs modifying formulae that don't need bottles or making changes that don't requ
Otherwise, you should use `brew pr-pull` (or `rebase`/`cherry-pick` contributions).
Don’t `rebase` until you finally `push`. Once `master` is pushed, you can’t `rebase`: **you’re a maintainer now!**
Don’t `rebase` until you finally `push`. Once `main` is pushed, you can’t `rebase`: **you’re a maintainer now!**
Cherry-picking changes the date of the commit, which kind of sucks.
@ -172,7 +172,7 @@ For an explanation of why this happens, read the [Ubuntu 11.04 Toolchain documen
Some formulae (e.g. Python, OpenSSL, ICU, Boost) have a large number of dependents. This makes updating these formulae (or their dependents) difficult because the standard procedure involves updating a large number of formulae in a single pull request. An alternative procedure that can significantly simplify this process is to use a staging branch.
The idea of using a staging branch is to merge updates and publish bottles for the affected formula to a non-default branch. This allows work to be done incrementally in smaller PRs, instead of in one giant PR that touches many formulae. When the staging branch is ready, it can be merged to the `master`/default branch.
The idea of using a staging branch is to merge updates and publish bottles for the affected formula to a non-default branch. This allows work to be done incrementally in smaller PRs, instead of in one giant PR that touches many formulae. When the staging branch is ready, it can be merged to the `main`/default branch.
Before making use of a staging branch, there is one important disadvantage to consider: once you have merged bottle updates to the staging branch, it is **very difficult** to take them back. This typically involves deleting uploaded bottles, which will occasionally require an owner of the Homebrew GitHub organisation to delete uploaded bottles one at a time.
@ -184,15 +184,15 @@ Here is a rough outline of how to use a staging branch:
1. Open an issue in homebrew-core inviting contributors to help. Be sure to include instructions for how to do so, and a checklist of formulae that need to be updated. See [Homebrew/homebrew-core#134251](https://github.com/Homebrew/homebrew-core/issues/134251) for an example.
1. Open a _draft_ PR that merges the staging branch into the `master` branch. This allows you to keep track of the work done so far. You may wish to apply the [`no long build conflict`](https://github.com/Homebrew/homebrew-core/labels/no%20long%20build%20conflict) label to this PR to avoid conflicting changes from being merged to the `master` branch.
1. Open a _draft_ PR that merges the staging branch into the `main` branch. This allows you to keep track of the work done so far. You may wish to apply the [`no long build conflict`](https://github.com/Homebrew/homebrew-core/labels/no%20long%20build%20conflict) label to this PR to avoid conflicting changes from being merged to the `main` branch.
1. Open PRs targeting the staging branch that update the affected formulae. Each PR should touch as few formulae as possible. The typical PR that targets the staging branch will update only one formula at a time. Staging branch PRs can be merged using the same process as PRs that target the `master` branch. Ideally, these PRs should be opened in [topological order](https://en.wikipedia.org/wiki/Topological_sorting) according to the dependency graph, but we don't currently have good tooling for generating a topological sort. (Help wanted.)
1. Open PRs targeting the staging branch that update the affected formulae. Each PR should touch as few formulae as possible. The typical PR that targets the staging branch will update only one formula at a time. Staging branch PRs can be merged using the same process as PRs that target the `main` branch. Ideally, these PRs should be opened in [topological order](https://en.wikipedia.org/wiki/Topological_sorting) according to the dependency graph, but we don't currently have good tooling for generating a topological sort. (Help wanted.)
1. Label PRs that target the staging branch with the [`staging-branch-pr`](https://github.com/Homebrew/homebrew-core/labels/staging-branch-pr) label for ease of tracking and review. (TODO: Add some automation for this to homebrew-core.)
1. Monitor the draft PR you created in step 3 above for merge conflicts. If you encounter a merge conflict, you must resolve those conflicts in a staging branch PR that merges the `master` branch into the staging branch.
1. Monitor the draft PR you created in step 3 above for merge conflicts. If you encounter a merge conflict, you must resolve those conflicts in a staging branch PR that merges the `main` branch into the staging branch.
1. When the staging branch is ready to be merged into `master`, mark the draft PR as ready for review and merge it into the `master` branch. Your PR may spend a long time in the merge queue waiting for the bottle fetch tests to run.
1. When the staging branch is ready to be merged into `main`, mark the draft PR as ready for review and merge it into the `main` branch. Your PR may spend a long time in the merge queue waiting for the bottle fetch tests to run.
For examples of uses of the staging branch, see homebrew-core PRs labelled [`openssl-3-migration-staging`](https://github.com/Homebrew/homebrew-core/labels/openssl-3-migration), [Homebrew/homebrew-core#134260](https://github.com/Homebrew/homebrew-core/pull/134260), or [Homebrew/homebrew-core#133611](https://github.com/Homebrew/homebrew-core/pull/133611).

8
docs/How-To-Open-a-Homebrew-Pull-Request.md
View File

@ -92,13 +92,13 @@ Before creating a new cask, please read [Acceptable Casks](Acceptable-Casks.md).
To make changes on a new branch and submit it for review, create a GitHub pull request with the following steps:
1. Check out the `master` branch:
1. Check out the `main` branch:
```sh
git checkout master
git checkout main
```
2. Retrieve new changes to the `master` branch:
2. Retrieve new changes to the `main` branch:
```sh
brew update
@ -157,7 +157,7 @@ To make changes based on feedback:
3. Squash new commits into one commit per formula:
```sh
git rebase --interactive origin/master
git rebase --interactive origin/HEAD
```
* If you are working on a PR for a single formula, `git commit --amend` is a convenient way of keeping your commits squashed as you go.