Skip to content

Clarify: adopted plugin branches must not merge master-forge into themselves #349

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
mbastian merged 1 commit into from
Sep 26, 2026
+4 −0
Merged

Clarify: adopted plugin branches must not merge master-forge into themselves #349

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -374,6 +374,10 @@ triggered by a fixed inactivity window, only by a real block a fork-based PR can
triggers, so a direct push there skips CI entirely.
- Never fork `master-forge` itself for this, or anything else — it aggregates every plugin in one
multi-module build, so a fork of it drags in every other plugin along with the one being adopted.
Merging `master-forge` *into* the adopted branch has the same effect via a merge commit instead of
a fork, and is just as much a mistake — the branch should only ever merge `master` to stay in sync.
The `<modules>`-list conflict against `master-forge` gets resolved when the PR actually lands, not
by pre-merging every other plugin's tree onto this branch beforehand.

The same applies to maintainer-driven bulk updates across many plugins at once (e.g. a Gephi version
bump): push to a short-lived branch and open a PR into `master-forge` rather than committing to it
Expand Down
Loading