Closed mmjconolly closed 4 years ago
Besides the speed gain of not having to perform the dependency resolution and being able to directly parallel clone, I'm thinking that this restore
command also provides a nice experience for those that might want to revision control their lockfiles.
$ git clone git@github.com/some-name/workspaces workspaces
Cloning into 'workspaces'...
done.
$ cd workspaces/
$ tree
.
|-- project1
| |-- wit-lock.json
| `-- wit-workspace.json
`-- project2
|-- wit-lock.json
`-- wit-workspace.json
$ cd project2
$ wit restore
Cloning repo1...
Cloning repo2...
Checking out 'repo1' at 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
Checking out 'repo2' at 'bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb'
$ ls
repo1 repo2 wit-lock.json wit-workspace.json
$ wit update-pkg repo1::cccccccccccccccccccccccccccccccccccccccc
$ git diff
diff --git a/project2/wit-workspace.json b/project2/wit-workspace.json
index aaaaaa..bbbbbb 100644
--- a/project2/wit-workspace.json
+++ b/project2/wit-workspace.json
@@ -1,6 +1,6 @@
[
{
- "commit": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
+ "commit": "cccccccccccccccccccccccccccccccccccccccc",
"name": "repo1",
"source": "git@github.com:user/repo1.git"
},
I've removed the --force option, it's usage was a little weird on already created workspaces (for example, forcing all the HEADs to what the lock says, but not dealing with unclean repos). So instead it's easier to just start by requiring that the workspace is 'new' and if we need a --force we can try figuring it out properly later
@mmjconolly I'll leave this for you to merge so you can decide if you want to squash or merge
Needed a small fixup due to the new jobs
param on Workspace
A
wit restore
will populate a fresh workspace using provided wit-workspace.json and wit-lock.json files. No dependency resolution happens.Resolves https://github.com/sifive/wit/issues/210