From e11952a2e0372d72164b4cb584a19af20ea1aa39 Mon Sep 17 00:00:00 2001 From: Mike McQuaid Date: Wed, 25 Jun 2025 08:49:58 +0100 Subject: [PATCH] docs: homebrew-core's default branch is now `main` Adjust documentation accordingly. --- docs/Formula-Cookbook.md | 4 ++-- docs/Homebrew-homebrew-core-Maintainer-Guide.md | 12 ++++++------ docs/How-To-Open-a-Homebrew-Pull-Request.md | 8 ++++---- 3 files changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/Formula-Cookbook.md b/docs/Formula-Cookbook.md index a94ffde80f..a901248c18 100644 --- a/docs/Formula-Cookbook.md +++ b/docs/Formula-Cookbook.md @@ -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 ``` diff --git a/docs/Homebrew-homebrew-core-Maintainer-Guide.md b/docs/Homebrew-homebrew-core-Maintainer-Guide.md index 7d2ea6addf..69d797ec48 100644 --- a/docs/Homebrew-homebrew-core-Maintainer-Guide.md +++ b/docs/Homebrew-homebrew-core-Maintainer-Guide.md @@ -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). diff --git a/docs/How-To-Open-a-Homebrew-Pull-Request.md b/docs/How-To-Open-a-Homebrew-Pull-Request.md index 7f1fe7c5dc..78f85b232c 100644 --- a/docs/How-To-Open-a-Homebrew-Pull-Request.md +++ b/docs/How-To-Open-a-Homebrew-Pull-Request.md @@ -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.