Skip to content

Keep the GPUI forks as patches, not as vendored trees - #12

Merged
SDSLeon merged 1 commit into
masterfrom
poracode/gpui-forks-as-patches
Sep 14, 2026
Merged

SDSLeon merged 1 commit into
masterfrom
poracode/gpui-forks-as-patches

Conversation

@SDSLeon

@SDSLeon SDSLeon commented Sep 14, 2026

Copy link
Copy Markdown
Contributor

[patch.crates-io] pointed at five in-tree copies of published packages — 207 files and roughly 153,000 lines, of which +1,644/−397 were ours. Those copies were a derived artifact: pinned published source plus the patches this repository already generates and verifies. This keeps only the smaller half.

247 files changed, 1,099 insertions, 158,984 deletions.

How it works

.shots/gpui_patches.py --materialize writes the pinned published packages into the gitignored .vendor/ tree and applies each patch exactly; [patch.crates-io] names those paths. --check no longer compares an in-tree fork against the registry — it proves each patch applies to the published source with no fuzz and reproduces .vendor/ byte for byte, so the patch stays the complete statement of the deviation.

The cost, stated plainly

Cargo resolves [patch] paths at manifest load, before any build script, so nothing can run earlier: a fresh clone must materialize before its first cargo command, rust-analyzer included, or cargo aborts with failed to load source for dependency. Every CI job that touches cargo runs the step first, through .github/actions/rust-env or its own copy. A warm run is a hash comparison finishing in under a second.

Verified, not assumed

Against a git archive extraction of this commit — a genuine fresh clone:

  • without the bootstrap, cargo metadata fails with the documented error (exit 101);
  • with it, cargo check --workspace --locked exits 0.

The cold-runner path was the real risk: a fresh runner has no gpui-pre in its registry, yet cargo cannot run in this workspace until .vendor/ exists. Tested with an empty CARGO_HOMEcargo info, run outside the workspace, breaks the cycle, and the resulting tree is byte-identical to the warm one.

Two things that had to keep working:

  • The gpui-pre-web fork's default = [] is what keeps wasm_thread out of the wasm32 graph and the wasm job on stable. It now arrives as a hunk in docs/upstream/patches/gpui-pre-web-0.3.3.patch; the wasm build succeeds on stable and cargo tree -i wasm_thread reports no such package.
  • The patches are build inputs on all three hosts now, so *.patch text eol=lf pins them — * text=auto would have handed the Windows runner CRLF copies that patch rejects.

No git dependency is introduced anywhere, so cargo publish is unaffected.

Local gates, all exit 0: run-tests.sh --workspace --locked (113/113) · clippy -D warnings · rustdoc -D warnings · fmt · hack --each-feature · deny · machete · gpui_patches --check/--self-test · inventory · coverage · all 14 parity audits · wasm.

🤖 Generated with Claude Code

`[patch.crates-io]` pointed at five in-tree copies of published packages --
207 files and roughly 153,000 lines, of which +1,644/-397 were ours. The
copies were a derived artifact: pinned published source plus the patches this
repository already generates and verifies. Keep only the smaller half.

`.shots/gpui_patches.py --materialize` now writes the pinned published
packages into the gitignored `.vendor/` tree and applies each patch exactly,
and `[patch.crates-io]` names those paths. `--check` no longer compares an
in-tree fork against the registry; it proves each patch applies to the
published source with no fuzz and reproduces `.vendor/` byte for byte, so the
patch stays the complete statement of the deviation.

Cargo resolves `[patch]` paths at manifest load, before any build script, so
there is no hook that can run earlier: a fresh clone must materialize before
its first cargo command, rust-analyzer included, or cargo aborts with `failed
to load source for dependency`. Every CI job that touches cargo runs the step
first, through `.github/actions/rust-env` or its own copy. A warm run is a
hash comparison that finishes in under a second.

Two things this had to keep working, both verified rather than assumed. The
`gpui-pre-web` fork's `default = []` is what keeps `wasm_thread` out of the
wasm32 graph and the wasm job on stable; it now reaches the build as a hunk in
`docs/upstream/patches/gpui-pre-web-0.3.3.patch`, and `cargo tree -i
wasm_thread` still reports no such package. And the patches are build inputs
on all three hosts now, so `*.patch text eol=lf` pins them -- `* text=auto`
would have handed the Windows runner CRLF copies that `patch` would reject.

No git dependency is introduced anywhere, so `cargo publish` is unaffected.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@vercel

vercel Bot commented Sep 14, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
herogpui Ready Ready Preview Sep 14, 2026 9:20pm UTC

Request Review

@SDSLeon
SDSLeon merged commit 31b1f0d into master Sep 14, 2026
13 checks passed
@SDSLeon
SDSLeon deleted the poracode/gpui-forks-as-patches branch September 14, 2026 21:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant