Skip to content

Proposal: Change how patches are managed and applied - #2967

Open
lex-ibm wants to merge 4 commits into
VSCodium:insiderfrom
lex-ibm:insider
Open

Proposal: Change how patches are managed and applied#2967
lex-ibm wants to merge 4 commits into
VSCodium:insiderfrom
lex-ibm:insider

Conversation

@lex-ibm

@lex-ibm lex-ibm commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

This PR has significant contributions made by AI.

My idea was to use the same mechanism as Electron does to apply their patches, mostly because I became tired of having to figure out what was mine and what was other people's work.

This is still a WIP, but feedback is always welcomed.

Patches apply as one git commit per patch on the pristine upstream checkout and
are stored as git-format-patch mailboxes, imported with `git am`. Import/export
is driven by Electron's patch core, vendored verbatim under dev/lib (MIT, see
dev/lib/NOTICE), with dev/lib/stack.py sequencing the VSCodium directories.

Each patch directory carries a `.patches` manifest listing its files in apply
order. Branding placeholders stay raw in the commits and are resolved in the
working tree at build time, so patch files round-trip unchanged.

`./dev/export.sh` regenerates patch files from the commits and self-verifies by
re-importing and comparing trees. The build refuses to discard uncommitted edits
or commits not yet exported; `-f` overrides.
Describe the commit-per-patch model, the `.patches` manifests, the authoring
and build tree states, and the edit/add/rebase recipes.
The patch stack is imported by a python helper, so every job that runs build.sh
needs python: drop the x64-only condition on the macOS setup-python steps and
add the step to the spearhead builds.
Re-sync the patch stack to VS Code 1.132.0 and re-export every patch as a
mailbox with its subject, rationale and original authorship restored.
@lex-ibm
lex-ibm marked this pull request as ready for review August 18, 2026 13:31
@daiyam

daiyam commented Aug 26, 2026

Copy link
Copy Markdown
Member

Ok, I've tested it.

Here, what I like:

  • The header in the patches. It's clearer about what they do.
  • To see the patch note in the commit message when edit a patch. It's nice.

What need to be improved:

  • It would be easier to track a patch by its filename than its subject (in the header)
    Applying: remove welcome onboarding screen, not clear which file is being applied, need to do search to find the file.
  • The support for json patches (like 52-ext-copilot-remove-it.json) need to be improved. Or to be skippable.
  • In the incoming, the patch code was mixed with old VSCode code. I had to check the patch to verify what it was doing. .rej is a bit easier here.
  • The rebase.sh is a bit of a black box. I wanted to stop after few patches. ./dev/export.sh told me to Finish or abort the rebase/am in vscode so I aborted it. Then, a second ./dev/export.sh didn't produce any new patches...

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.

2 participants