Conversation
|
Wouldn't it be easier to make this a regular Miri PR? |
|
|
||
| Every time: | ||
|
|
||
| Note: the first time you run this, `git subtree` builds a cache and this command may thusly take an hour or so. |
There was a problem hiding this comment.
An hour?!??? :(
I have many rustc checkouts. How can I make it share the cache between my checkouts?
There was a problem hiding this comment.
I have no idea, this worked faster for clippy and other repos...
There was a problem hiding this comment.
If you use git worktree for creating the extra git checkouts I believe the subtree cache is shared. Not entirely sure though.
I have no idea, this worked faster for clippy and other repos...
The first common commit between rust and miri is from 2018 (when rust-lang/rust#46882 merged it into rustc as const eval engine). Git subtree has to walk all commits since then I believe.
There was a problem hiding this comment.
yea, that's not really useful... why doesn't it just walk the subtree_add_commit..HEAD range and rewrite those commits...
| git remote add miri https://github.com/rust-lang/miri.git | ||
| ``` | ||
|
|
||
| Every time: |
There was a problem hiding this comment.
Does this also need that cache or is this always fast(er)?
There was a problem hiding this comment.
this is always fast, just a few seconds at most, does not get slower with time
it is a regular miri PR, there was just a collision with the miri subtree push that has been running for 3h now 😱 idk what's going on (yes I do have the patch). And that push was started with the same name as the previous branch name, and would have failed at the end. I am currently figuring out what the perf issue is, and why I didn't see it while working on the PR |
|
@rustbot author |
|
☔ The latest upstream changes (presumably #2568) made this pull request unmergeable. Please resolve the merge conflicts. |
make sentence more simple
supercedes #2560 (sorry for all the PRs, I needed the branch clean as I was git subtree pushing to it)