|
2 | 2 | <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> |
3 | 3 | # Maintaining |
4 | 4 |
|
5 | | -- [Team](#team) |
6 | | - - [Onboarding](#onboarding) |
7 | | - - [Offboarding](#offboarding) |
8 | | -- [Workflow](#workflow) |
9 | | - - [Milestones](#milestones) |
10 | | - - [Triage](#triage) |
11 | | - - [Project boards](#project-boards) |
12 | | -- [Versioning](#versioning) |
13 | | -- [Pull requests](#pull-requests) |
14 | | - - [Merge strategies](#merge-strategies) |
15 | | - - [Changelog](#changelog) |
16 | | -- [Releases](#releases) |
17 | | - - [Publishing a release](#publishing-a-release) |
18 | | - - [AUR](#aur) |
19 | | - - [Docker](#docker) |
20 | | - - [Homebrew](#homebrew) |
21 | | - - [npm](#npm) |
22 | | -- [Testing](#testing) |
23 | | -- [Documentation](#documentation) |
24 | | - - [Troubleshooting](#troubleshooting) |
| 5 | +- [Maintaining](#maintaining) |
| 6 | + - [Team](#team) |
| 7 | + - [Onboarding](#onboarding) |
| 8 | + - [Offboarding](#offboarding) |
| 9 | + - [Workflow](#workflow) |
| 10 | + - [Milestones](#milestones) |
| 11 | + - [Triage](#triage) |
| 12 | + - [Project boards](#project-boards) |
| 13 | + - [Versioning](#versioning) |
| 14 | + - [Pull requests](#pull-requests) |
| 15 | + - [Merge strategies](#merge-strategies) |
| 16 | + - [Changelog](#changelog) |
| 17 | + - [Releases](#releases) |
| 18 | + - [Publishing a release](#publishing-a-release) |
| 19 | + - [AUR](#aur) |
| 20 | + - [Docker](#docker) |
| 21 | + - [Homebrew](#homebrew) |
| 22 | + - [npm](#npm) |
| 23 | + - [Syncing with Upstream VS Code](#syncing-with-upstream-vs-code) |
| 24 | + - [Testing](#testing) |
| 25 | + - [Documentation](#documentation) |
| 26 | + - [Troubleshooting](#troubleshooting) |
25 | 27 |
|
26 | 28 | <!-- END doctoc generated TOC please keep comment here to allow auto update --> |
27 | 29 |
|
@@ -126,8 +128,7 @@ the issue. |
126 | 128 |
|
127 | 129 | ### Merge strategies |
128 | 130 |
|
129 | | -For most things, we recommend the **squash and merge** strategy. If you're |
130 | | -updating `lib/vscode`, we suggest using the **rebase and merge** strategy. There |
| 131 | +For most things, we recommend the **squash and merge** strategy. There |
131 | 132 | may be times where **creating a merge commit** makes sense as well. Use your |
132 | 133 | best judgment. If you're unsure, you can always discuss in the PR with the team. |
133 | 134 |
|
@@ -215,6 +216,17 @@ We publish code-server as a npm package [here](https://www.npmjs.com/package/cod |
215 | 216 |
|
216 | 217 | This is currently automated with the release process. |
217 | 218 |
|
| 219 | +## Syncing with Upstream VS Code |
| 220 | + |
| 221 | +The VS Code portion of code-server lives under [`cdr/vscode`](https://github.com/cdr/vscode). To update VS Code for code-server, follow these steps: |
| 222 | +1. `git checkout -b vscode-update` - Create a new branch locally based off `main` |
| 223 | +2. `git fetch upstream` - Fetch upstream (VS Code)'s latest `main` branch |
| 224 | +3. `git merge upstream/main` - Merge it locally |
| 225 | + 1. If there are merge conflicts, fix them locally |
| 226 | +4. Open a PR merging your branch (`vscode-update`) into `main` and add the code-server review team |
| 227 | + |
| 228 | +Ideally, our fork stays as close to upstream as possible. See the differences between our fork and upstream [here](https://github.com/microsoft/vscode/compare/main...cdr:main). |
| 229 | + |
218 | 230 | ## Testing |
219 | 231 |
|
220 | 232 | Our testing structure is laid out under our [Contributing docs](https://coder.com/docs/code-server/latest/CONTRIBUTING#test). |
|
0 commit comments