fix: forced monorepo splits fail during cleanup by imorland · Pull Request #52 · flarum/cli

imorland · 2026-07-31T23:59:40Z

Two bugs in monorepo:split --force, both found by using it regularly on the Flarum monorepo.

Cleanup deletes a branch that a forced split never creates

splitAndPush() only creates the <remote>-tmp branch on the non-forced path:

if(force){execSync(`git push --force ${pushArgs}`,{ cwd });// pushes the sha directly}else{execSync(`git switch -c ${tmpBranch}${sha1}`,{ cwd });…}

but cleanupBranchAndRemote() ran git branch -D <remote>-tmp unconditionally. So every forced split threw once all the pushes had already succeeded — the work was done, the command still ended in an error.

`--force` ignored `--no-interaction`

The force confirmation is a confirm param with initial: false. In non-interactive mode PromptsIO::getParam() returns the initial value rather than prompting, so the answer was always "no" and monorepo:split --force --no-interaction reliably printed "Decided not to force push" and did nothing.

That's precisely the flag combination a script or CI job would use, and it silently no-oped. The confirmation is now skipped when the operator has already asked not to be prompted — --no-interaction means "don't ask me", so a forced split proceeds.

Worth being deliberate about: this makes --force --no-interaction genuinely force-push to every split repo without confirmation. That is the intent of the flag pair, and the guard remains for interactive use.

Verification

yarn test — 22 suites, 176 tests, Prettier clean. Both paths exercised by hand against the Flarum monorepo on Apple silicon over an extended period.

splitAndPush only creates the <remote>-tmp branch on the non-forced path — a forced split pushes the split sha straight to the remote — but cleanupBranchAndRemote deleted that branch unconditionally, so every forced split ended in a git error once the pushes had succeeded. Forced splits also ignored --no-interaction. getParam answers a confirm with its initial value in non-interactive mode, and this one starts at false, so 'monorepo:split --force --no-interaction' always took the 'decided not to force push' path and quietly did nothing — which is exactly the combination a script or CI job would use. The confirmation is now skipped when the operator has already asked for no prompts.

imorland · 2026-07-31T23:59:40Z

Two bugs in monorepo:split --force, both found by using it regularly on the Flarum monorepo.

Cleanup deletes a branch that a forced split never creates

splitAndPush() only creates the <remote>-tmp branch on the non-forced path:

if(force){execSync(`git push --force ${pushArgs}`,{ cwd });// pushes the sha directly}else{execSync(`git switch -c ${tmpBranch}${sha1}`,{ cwd });…}

but cleanupBranchAndRemote() ran git branch -D <remote>-tmp unconditionally. So every forced split threw once all the pushes had already succeeded — the work was done, the command still ended in an error.

`--force` ignored `--no-interaction`

The force confirmation is a confirm param with initial: false. In non-interactive mode PromptsIO::getParam() returns the initial value rather than prompting, so the answer was always "no" and monorepo:split --force --no-interaction reliably printed "Decided not to force push" and did nothing.

That's precisely the flag combination a script or CI job would use, and it silently no-oped. The confirmation is now skipped when the operator has already asked not to be prompted — --no-interaction means "don't ask me", so a forced split proceeds.

Worth being deliberate about: this makes --force --no-interaction genuinely force-push to every split repo without confirmation. That is the intent of the flag pair, and the guard remains for interactive use.

Verification

yarn test — 22 suites, 176 tests, Prettier clean. Both paths exercised by hand against the Flarum monorepo on Apple silicon over an extended period.

splitAndPush only creates the <remote>-tmp branch on the non-forced path — a forced split pushes the split sha straight to the remote — but cleanupBranchAndRemote deleted that branch unconditionally, so every forced split ended in a git error once the pushes had succeeded. Forced splits also ignored --no-interaction. getParam answers a confirm with its initial value in non-interactive mode, and this one starts at false, so 'monorepo:split --force --no-interaction' always took the 'decided not to force push' path and quietly did nothing — which is exactly the combination a script or CI job would use. The confirmation is now skipped when the operator has already asked for no prompts.

imorland · 2026-07-31T23:59:40Z

Two bugs in monorepo:split --force, both found by using it regularly on the Flarum monorepo.

Cleanup deletes a branch that a forced split never creates

splitAndPush() only creates the <remote>-tmp branch on the non-forced path:

if(force){execSync(`git push --force ${pushArgs}`,{ cwd });// pushes the sha directly}else{execSync(`git switch -c ${tmpBranch}${sha1}`,{ cwd });…}

but cleanupBranchAndRemote() ran git branch -D <remote>-tmp unconditionally. So every forced split threw once all the pushes had already succeeded — the work was done, the command still ended in an error.

`--force` ignored `--no-interaction`

The force confirmation is a confirm param with initial: false. In non-interactive mode PromptsIO::getParam() returns the initial value rather than prompting, so the answer was always "no" and monorepo:split --force --no-interaction reliably printed "Decided not to force push" and did nothing.

That's precisely the flag combination a script or CI job would use, and it silently no-oped. The confirmation is now skipped when the operator has already asked not to be prompted — --no-interaction means "don't ask me", so a forced split proceeds.

Worth being deliberate about: this makes --force --no-interaction genuinely force-push to every split repo without confirmation. That is the intent of the flag pair, and the guard remains for interactive use.

Verification

yarn test — 22 suites, 176 tests, Prettier clean. Both paths exercised by hand against the Flarum monorepo on Apple silicon over an extended period.

splitAndPush only creates the <remote>-tmp branch on the non-forced path — a forced split pushes the split sha straight to the remote — but cleanupBranchAndRemote deleted that branch unconditionally, so every forced split ended in a git error once the pushes had succeeded. Forced splits also ignored --no-interaction. getParam answers a confirm with its initial value in non-interactive mode, and this one starts at false, so 'monorepo:split --force --no-interaction' always took the 'decided not to force push' path and quietly did nothing — which is exactly the combination a script or CI job would use. The confirmation is now skipped when the operator has already asked for no prompts.

imorland · 2026-07-31T23:59:40Z

Two bugs in monorepo:split --force, both found by using it regularly on the Flarum monorepo.

Cleanup deletes a branch that a forced split never creates

splitAndPush() only creates the <remote>-tmp branch on the non-forced path:

if(force){execSync(`git push --force ${pushArgs}`,{ cwd });// pushes the sha directly}else{execSync(`git switch -c ${tmpBranch}${sha1}`,{ cwd });…}

but cleanupBranchAndRemote() ran git branch -D <remote>-tmp unconditionally. So every forced split threw once all the pushes had already succeeded — the work was done, the command still ended in an error.

`--force` ignored `--no-interaction`

The force confirmation is a confirm param with initial: false. In non-interactive mode PromptsIO::getParam() returns the initial value rather than prompting, so the answer was always "no" and monorepo:split --force --no-interaction reliably printed "Decided not to force push" and did nothing.

That's precisely the flag combination a script or CI job would use, and it silently no-oped. The confirmation is now skipped when the operator has already asked not to be prompted — --no-interaction means "don't ask me", so a forced split proceeds.

Worth being deliberate about: this makes --force --no-interaction genuinely force-push to every split repo without confirmation. That is the intent of the flag pair, and the guard remains for interactive use.

Verification

yarn test — 22 suites, 176 tests, Prettier clean. Both paths exercised by hand against the Flarum monorepo on Apple silicon over an extended period.

splitAndPush only creates the <remote>-tmp branch on the non-forced path — a forced split pushes the split sha straight to the remote — but cleanupBranchAndRemote deleted that branch unconditionally, so every forced split ended in a git error once the pushes had succeeded. Forced splits also ignored --no-interaction. getParam answers a confirm with its initial value in non-interactive mode, and this one starts at false, so 'monorepo:split --force --no-interaction' always took the 'decided not to force push' path and quietly did nothing — which is exactly the combination a script or CI job would use. The confirmation is now skipped when the operator has already asked for no prompts.

imorland · 2026-07-31T23:59:40Z

Two bugs in monorepo:split --force, both found by using it regularly on the Flarum monorepo.

Cleanup deletes a branch that a forced split never creates

splitAndPush() only creates the <remote>-tmp branch on the non-forced path:

if(force){execSync(`git push --force ${pushArgs}`,{ cwd });// pushes the sha directly}else{execSync(`git switch -c ${tmpBranch}${sha1}`,{ cwd });…}

but cleanupBranchAndRemote() ran git branch -D <remote>-tmp unconditionally. So every forced split threw once all the pushes had already succeeded — the work was done, the command still ended in an error.

`--force` ignored `--no-interaction`

The force confirmation is a confirm param with initial: false. In non-interactive mode PromptsIO::getParam() returns the initial value rather than prompting, so the answer was always "no" and monorepo:split --force --no-interaction reliably printed "Decided not to force push" and did nothing.

That's precisely the flag combination a script or CI job would use, and it silently no-oped. The confirmation is now skipped when the operator has already asked not to be prompted — --no-interaction means "don't ask me", so a forced split proceeds.

Worth being deliberate about: this makes --force --no-interaction genuinely force-push to every split repo without confirmation. That is the intent of the flag pair, and the guard remains for interactive use.

Verification

yarn test — 22 suites, 176 tests, Prettier clean. Both paths exercised by hand against the Flarum monorepo on Apple silicon over an extended period.

splitAndPush only creates the <remote>-tmp branch on the non-forced path — a forced split pushes the split sha straight to the remote — but cleanupBranchAndRemote deleted that branch unconditionally, so every forced split ended in a git error once the pushes had succeeded. Forced splits also ignored --no-interaction. getParam answers a confirm with its initial value in non-interactive mode, and this one starts at false, so 'monorepo:split --force --no-interaction' always took the 'decided not to force push' path and quietly did nothing — which is exactly the combination a script or CI job would use. The confirmation is now skipped when the operator has already asked for no prompts.

imorland · 2026-07-31T23:59:40Z

Two bugs in monorepo:split --force, both found by using it regularly on the Flarum monorepo.

Cleanup deletes a branch that a forced split never creates

splitAndPush() only creates the <remote>-tmp branch on the non-forced path:

if(force){execSync(`git push --force ${pushArgs}`,{ cwd });// pushes the sha directly}else{execSync(`git switch -c ${tmpBranch}${sha1}`,{ cwd });…}

but cleanupBranchAndRemote() ran git branch -D <remote>-tmp unconditionally. So every forced split threw once all the pushes had already succeeded — the work was done, the command still ended in an error.

`--force` ignored `--no-interaction`

The force confirmation is a confirm param with initial: false. In non-interactive mode PromptsIO::getParam() returns the initial value rather than prompting, so the answer was always "no" and monorepo:split --force --no-interaction reliably printed "Decided not to force push" and did nothing.

That's precisely the flag combination a script or CI job would use, and it silently no-oped. The confirmation is now skipped when the operator has already asked not to be prompted — --no-interaction means "don't ask me", so a forced split proceeds.

Worth being deliberate about: this makes --force --no-interaction genuinely force-push to every split repo without confirmation. That is the intent of the flag pair, and the guard remains for interactive use.

Verification

yarn test — 22 suites, 176 tests, Prettier clean. Both paths exercised by hand against the Flarum monorepo on Apple silicon over an extended period.

splitAndPush only creates the <remote>-tmp branch on the non-forced path — a forced split pushes the split sha straight to the remote — but cleanupBranchAndRemote deleted that branch unconditionally, so every forced split ended in a git error once the pushes had succeeded. Forced splits also ignored --no-interaction. getParam answers a confirm with its initial value in non-interactive mode, and this one starts at false, so 'monorepo:split --force --no-interaction' always took the 'decided not to force push' path and quietly did nothing — which is exactly the combination a script or CI job would use. The confirmation is now skipped when the operator has already asked for no prompts.

imorland · 2026-07-31T23:59:40Z

Two bugs in monorepo:split --force, both found by using it regularly on the Flarum monorepo.

Cleanup deletes a branch that a forced split never creates

splitAndPush() only creates the <remote>-tmp branch on the non-forced path:

if(force){execSync(`git push --force ${pushArgs}`,{ cwd });// pushes the sha directly}else{execSync(`git switch -c ${tmpBranch}${sha1}`,{ cwd });…}

but cleanupBranchAndRemote() ran git branch -D <remote>-tmp unconditionally. So every forced split threw once all the pushes had already succeeded — the work was done, the command still ended in an error.

`--force` ignored `--no-interaction`

The force confirmation is a confirm param with initial: false. In non-interactive mode PromptsIO::getParam() returns the initial value rather than prompting, so the answer was always "no" and monorepo:split --force --no-interaction reliably printed "Decided not to force push" and did nothing.

That's precisely the flag combination a script or CI job would use, and it silently no-oped. The confirmation is now skipped when the operator has already asked not to be prompted — --no-interaction means "don't ask me", so a forced split proceeds.

Worth being deliberate about: this makes --force --no-interaction genuinely force-push to every split repo without confirmation. That is the intent of the flag pair, and the guard remains for interactive use.

Verification

yarn test — 22 suites, 176 tests, Prettier clean. Both paths exercised by hand against the Flarum monorepo on Apple silicon over an extended period.

splitAndPush only creates the <remote>-tmp branch on the non-forced path — a forced split pushes the split sha straight to the remote — but cleanupBranchAndRemote deleted that branch unconditionally, so every forced split ended in a git error once the pushes had succeeded. Forced splits also ignored --no-interaction. getParam answers a confirm with its initial value in non-interactive mode, and this one starts at false, so 'monorepo:split --force --no-interaction' always took the 'decided not to force push' path and quietly did nothing — which is exactly the combination a script or CI job would use. The confirmation is now skipped when the operator has already asked for no prompts.

imorland · 2026-07-31T23:59:40Z

Two bugs in monorepo:split --force, both found by using it regularly on the Flarum monorepo.

Cleanup deletes a branch that a forced split never creates

splitAndPush() only creates the <remote>-tmp branch on the non-forced path:

if(force){execSync(`git push --force ${pushArgs}`,{ cwd });// pushes the sha directly}else{execSync(`git switch -c ${tmpBranch}${sha1}`,{ cwd });…}

but cleanupBranchAndRemote() ran git branch -D <remote>-tmp unconditionally. So every forced split threw once all the pushes had already succeeded — the work was done, the command still ended in an error.

`--force` ignored `--no-interaction`

The force confirmation is a confirm param with initial: false. In non-interactive mode PromptsIO::getParam() returns the initial value rather than prompting, so the answer was always "no" and monorepo:split --force --no-interaction reliably printed "Decided not to force push" and did nothing.

That's precisely the flag combination a script or CI job would use, and it silently no-oped. The confirmation is now skipped when the operator has already asked not to be prompted — --no-interaction means "don't ask me", so a forced split proceeds.

Worth being deliberate about: this makes --force --no-interaction genuinely force-push to every split repo without confirmation. That is the intent of the flag pair, and the guard remains for interactive use.

Verification

yarn test — 22 suites, 176 tests, Prettier clean. Both paths exercised by hand against the Flarum monorepo on Apple silicon over an extended period.

splitAndPush only creates the <remote>-tmp branch on the non-forced path — a forced split pushes the split sha straight to the remote — but cleanupBranchAndRemote deleted that branch unconditionally, so every forced split ended in a git error once the pushes had succeeded. Forced splits also ignored --no-interaction. getParam answers a confirm with its initial value in non-interactive mode, and this one starts at false, so 'monorepo:split --force --no-interaction' always took the 'decided not to force push' path and quietly did nothing — which is exactly the combination a script or CI job would use. The confirmation is now skipped when the operator has already asked for no prompts.

imorland merged commit 24f5046 into 3.xAug 1, 2026
3 checks passed

imorland deleted the im/fix-force-split branch August 1, 2026 00:01