You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When sphinx-codelinks was imported (#1871), eight pull requests were open in the old repository. Each carries a note pointing at the move recipe in #1871's description ("If you have an open pull request in the old repository"), and the old repository is frozen behind its pinned notice (useblocks/sphinx-codelinks#107). This issue holds the list and the decisions, so nothing is lost while they wait.
tests only; measured before the import to move with zero conflicts
"Conflicting" means against the old repository's own main after its three pre-import pull requests landed, so each of those seven needs a rebase there before the recipe applies.
How a move works
The recipe rewrites the branch with the same git filter-repo rule the import used, so its commits apply on top of the import with their authorship intact. A moved pull request is opened here by whoever runs the recipe, credits the original author through the preserved commits, and the original is closed with a pointer. External contributors are not expected to run this themselves.
For the rest: move, ask the author, or close as superseded — per PR, from the measured table below once it is in.
Measured move results
Measured on 2026-09-06/07 in scratch clones against master 758a43f2 and the old main63adfe50, following the recipe verbatim for every PR: rebase onto the old main first, then git filter-repo with the import's rule (which put main on the exact commit the import merged, all eight times), then onto master, then the codelinks suite on the result (baseline 359 passed). Nothing was pushed.
The three marked-RST approaches solve one issue (#1885, old #43) at three different layers.#99 hands each block to docutils inside the directive, so any RST renders, adds no configuration key, and is the smallest and the only non-draft one. #66 drives sphinx-needs' NeedDirective from a regex-parsed first directive, renders need directives only, and needs a sphinx-needs 6 floor bump its own description leaves undecided; its rst_mixed fixture is worth transplanting onto #99. #44 parses blocks with a Lark grammar in the analyse layer so the CLI's JSON carries structured needs, at the cost of a new runtime dependency and three configuration keys; it is really a different feature, aimed at non-Sphinx consumers, and is nine months stale with changes requested. #66 and #99 add a render method to the same file and would render every block twice if both landed. The measured recommendation: #99 survives; #66 folds in as a follow-up; #44 becomes an issue. The decision stays open here until it is taken.
Two things the recipe's own list does not name, learned on the way: the import re-sorted the imports in src_trace.py because sphinx_needs is first-party in the workspace, so any branch touching that import block conflicts at the recipe stage even after a clean rebase (it hit #66 and #99, one line each time); and git's rename detection carried the moved changelog for some branches and silently dropped the hunk for others, so every moved PR's changelog entry has to be checked by eye.
Also for whoever moves them: #99's title still says "(#43)" and should name #1885; #100's file list is capped at 100 by the API, the branch has 153.
When sphinx-codelinks was imported (#1871), eight pull requests were open in the old repository. Each carries a note pointing at the move recipe in #1871's description ("If you have an open pull request in the old repository"), and the old repository is frozen behind its pinned notice (useblocks/sphinx-codelinks#107). This issue holds the list and the decisions, so nothing is lost while they wait.
main@rstblocks-W/--strictand sharedsuppress_warningsCommentType.markdownvia tree-sittersrc-trace"Conflicting" means against the old repository's own
mainafter its three pre-import pull requests landed, so each of those seven needs a rebase there before the recipe applies.How a move works
The recipe rewrites the branch with the same
git filter-reporule the import used, so its commits apply on top of the import with their authorship intact. A moved pull request is opened here by whoever runs the recipe, credits the original author through the preserved commits, and the original is closed with a pointer. External contributors are not expected to run this themselves.Decisions, deliberately deferred
-W/--strictoverlaps with the same flag in sphinx-test-reports#148; one design for both is preferable to two.Measured move results
Measured on 2026-09-06/07 in scratch clones against master
758a43f2and the oldmain63adfe50, following the recipe verbatim for every PR: rebase onto the oldmainfirst, thengit filter-repowith the import's rule (which putmainon the exact commit the import merged, all eight times), then onto master, then the codelinks suite on the result (baseline 359 passed). Nothing was pushed.mainrebase@rstblocks (chrisjsewell, draft)test_analyse_oneline_needs-W/--strict(ubmarco, draft)analyse/utils.pygit helpersrc-trace(cpolzer)-nWgreenThe three marked-RST approaches solve one issue (#1885, old #43) at three different layers. #99 hands each block to docutils inside the directive, so any RST renders, adds no configuration key, and is the smallest and the only non-draft one. #66 drives sphinx-needs'
NeedDirectivefrom a regex-parsed first directive, renders need directives only, and needs a sphinx-needs 6 floor bump its own description leaves undecided; itsrst_mixedfixture is worth transplanting onto #99. #44 parses blocks with a Lark grammar in the analyse layer so the CLI's JSON carries structured needs, at the cost of a new runtime dependency and three configuration keys; it is really a different feature, aimed at non-Sphinx consumers, and is nine months stale with changes requested. #66 and #99 add a render method to the same file and would render every block twice if both landed. The measured recommendation: #99 survives; #66 folds in as a follow-up; #44 becomes an issue. The decision stays open here until it is taken.Two things the recipe's own list does not name, learned on the way: the import re-sorted the imports in
src_trace.pybecausesphinx_needsis first-party in the workspace, so any branch touching that import block conflicts at the recipe stage even after a clean rebase (it hit #66 and #99, one line each time); and git's rename detection carried the moved changelog for some branches and silently dropped the hunk for others, so every moved PR's changelog entry has to be checked by eye.Also for whoever moves them: #99's title still says "(#43)" and should name #1885; #100's file list is capped at 100 by the API, the branch has 153.