From 054b31c2504936d92a5849cf85c9a2518497292f Mon Sep 17 00:00:00 2001 From: Mathieu Bastian Date: Sat, 26 Sep 2026 09:55:16 +0200 Subject: [PATCH] Clarify: adopted plugin branches must not merge master-forge into themselves MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A branch adopted per "When a plugin's fork stops being a reliable source of truth" should only ever sync with master. Merging master-forge into it to pre-resolve the -list conflict has the same effect as forking master-forge outright — every other plugin's tree ends up permanently on the branch — just reached via a merge commit instead of a clone. Co-Authored-By: Claude Sonnet 5 --- CONTRIBUTING.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 71bfa655d..17d4c09ec 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -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 ``-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