Skip to content

git: enable subprocessing by default #5652

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 10, 2025
Merged

Conversation

emilazy
Copy link
Contributor

@emilazy emilazy commented Feb 10, 2025

Given the previously‐stated intention of making this default for the 0.27 release, prepare for that decision ahead of time by enabling subprocessing by default on trunk. This will help surface any regressions and workflow incompatibilities and therefore give us more information to decide whether to keep or revert this commit, without inconveniencing any users who haven’t already opted in to the bleeding edge.

Please feel free to revert without hesitation if any major issues arise; this is not intended as a strong commitment to enable this option for the next stable release if it turns out to not be ready. In that case, it’s better that we learn that early on in the cycle, rather than having to revert at the last minute or, worse, cutting a stable release that we later find contains a serious regression.

Checklist

If applicable:

  • I have updated CHANGELOG.md
  • I have updated the documentation (README.md, docs/, demos/)
  • I have updated the config schema (cli/src/config-schema.json)
  • I have added tests to cover my changes

Given the previously‐stated intention of making this default
for the 0.27 release, prepare for that decision ahead of time by
enabling subprocessing by default on trunk. This will help surface
any regressions and workflow incompatibilities and therefore give
us more information to decide whether to keep or revert this commit,
without inconveniencing any users who haven’t already opted in to
the bleeding edge.

Please feel free to revert without hesitation if any major issues
arise; this is not intended as a strong commitment to enable this
option for the next stable release if it turns out to not be ready. In
that case, it’s better that we learn that early on in the cycle,
rather than having to revert at the last minute or, worse, cutting
a stable release that we later find contains a serious regression.
@emilazy emilazy added this pull request to the merge queue Feb 10, 2025
Merged via the queue into jj-vcs:main with commit 77f54a2 Feb 10, 2025
40 of 41 checks passed
@emilazy emilazy deleted the push-umtyowvvsouz branch February 10, 2025 23:15
@emilazy emilazy mentioned this pull request Feb 10, 2025
11 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants