Make default-branch references rename-safe - #502
Merged
Merged
Conversation
Point the readme changelog link at blob/HEAD (resolves to whatever the default branch is) and reword the contributing guide to say "default branch" instead of "master", so both survive a default-branch rename. Co-Authored-By: Claude Fable 5 <[email protected]>
There was a problem hiding this comment.
Pull request overview
This PR makes default-branch references rename-safe after the repository’s default branch rename by removing remaining master references and using a branch-agnostic GitHub link.
Changes:
- Updated
readme.txtchangelog link to useblob/HEAD/...so it follows the repository’s default branch. - Reworded
.github/CONTRIBUTING.mdto refer to a contributor’s “default branch” instead of “master”.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| readme.txt | Updates the changelog URL to be default-branch/rename safe via HEAD. |
| .github/CONTRIBUTING.md | Rewords contributor guidance to avoid master terminology and be branch-neutral. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
|
||
| 1. A pull request should encompass only a *single* idea. Not "general cleanup" or "a bunch of assorted changes I made to my fork of the repository". One pull request = one change. | ||
| 2. A pull request should come from a *branch* you made in your fork of the repository. Not from your master copy. If you want to work on a specific problem, then make a fork of the repo, and then branch that fork to encompass what you're going to be working on. Then, when you submit the pull-request, you can switch back to your master or another branch and work on something else without polluting the pull request with other unrelated changes. | ||
| 2. A pull request should come from a *branch* you made in your fork of the repository. Not from your default branch. If you want to work on a specific problem, then make a fork of the repo, and then branch that fork to encompass what you're going to be working on. Then, when you submit the pull-request, you can switch back to your default or another branch and work on something else without polluting the pull request with other unrelated changes. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #484.
Follow-up to renaming the default branch to
trunk: removes the remainingmasterreferences so nothing points at a dead branch.readme.txt: the changelog link now points atblob/HEAD/changelog.txt, which GitHub resolves to whatever the default branch is — correct now and after any future rename. (This link is also published on the wp.org plugin page.).github/CONTRIBUTING.md: reworded the "master" mentions to "default branch"; the guidance is about a contributor's own fork, so branch-neutral wording is clearer and rename-proof.No workflow changes are needed —
phpcs.ymlruns on[push, pull_request]anddeploy.ymlonrelease: published, both branch-agnostic.