fork every time we see a non-trivial marker ("aggressive" forking) #6143
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a revival of #5733 on top of current
main
, as many thingshave changed since #5733.
It is suspected that, at least at this time, we probably don't
want to switch to aggressive forking, but we may in the future. In
particular, aggressive forking does fix #4668 and #6127.
Moreover, it fixes some issues that aren't filed but for which we only
have hand-crafted artificial examples (see the
non-local-*
packsescenarios).
There are two main downsides to aggressive forking:
overall, sometimes dramatically so.
understand. Part of the point of this PR is to be able to look at the
snapshot diffs to see the kinds of effects it has. In some cases, the
changes are quite large and can be difficult to comprehend and reason
about.
We haven't spent a ton of time on (1), but it is suspected that in the
aggressive strategy, there should still be a way to prune superfluous
forks.