VS Code 1.48.0 #1982
VS Code 1.48.0 #1982
Conversation
code-asher
force-pushed
the
vscode-1.48.0
branch
from
85f6173 to
baa6459
Compare
code-asher
force-pushed
the
vscode-1.48.0
branch
from
baa6459 to
488f7c1
Compare
|
Thoughts on merging into a Would avoid confusion re the version in package.json and documentation updates for things that haven't made it into master. |
There was a problem hiding this comment.
In the future we should try to make smaller direct commits.
It's hard to review when there's little context on every change made. And I fully disagree with my previous comments on this matter, we need a git subtree. This is soooo confusing to review. I can't tell if the changes are made by you or in the patch already without looking all the way over to the left.
| @@ -1,7 +1,7 @@ | |||
| { | |||
| "name": "code-server", | |||
| "license": "MIT", | |||
| "version": "3.4.1", | |||
| "version": "3.5.0", | |||
| "description": "Dependencies shared by all extensions", | ||
| + "dependencies_comment": "Move rimraf to dependencies because it is used in the postinstall script.", | ||
| "dependencies": { | ||
| + "rimraf": "^3.0.2", |
There was a problem hiding this comment.
Do we not need our rimraf patch now?
There was a problem hiding this comment.
We do, but they no longer install it here and rely on the package in the root so I moved it to dependencies in the root.
| import { isEqual } from 'vs/base/common/resources'; | ||
| import { isStandalone } from 'vs/base/browser/browser'; | ||
| import { localize } from 'vs/nls'; |
There was a problem hiding this comment.
why do we need to add this?
There was a problem hiding this comment.
This was added by VS Code so it's part of the context in the patch.
|
Lack of a git subtree is also contributing to massive commits to the patch. |
|
I'm definitely in favor of something other than a patch. I'm not 100% convinced about the subtree route vs something like a fork + submodule (doesn't a subtree bring all of VS Code's commits into our repo?) but anything has got to be better than this. |
|
@code-asher how about smaller patchfiles instead of one massive? The buildscript could be easily modified to take a folder instead of a file, and then the typical Linux style filename-based ordering could be used (so you'd end up with files like As for branch management, I'd recommend looking into git-flow - I've been using it for years at various companies (even some Microsoft Partner companies!), and so far it's the best approach at a sensible branch naming strategy. |
|
Smaller patchfiles do seem like would help reviewability, and maybe even with conflict resolution. I think many of the core issues remain though so I'd be happier without any patches. 😄 |
|
Whoops, meant to link #1587 |
No description provided.