fix: rm -rf before restoring .github/workflows, not just checkout -- - #59
Merged
Merged
Conversation
#58's restoration step (git checkout origin/main -- .github/workflows) looked right but was a no-op for exactly the case that matters: a workflow_dispatch run just failed again with the identical integration_tests.yml rejection. git checkout <ref> -- <path> only overwrites paths that already exist in <ref>. It doesn't delete files present in the working tree/index but absent from <ref> — so a brand-new file the merge just pulled in from upstream (origin/main never had it) survives untouched, and the push still gets rejected for it. Verified locally with a throwaway git sandbox reproducing the exact scenario (origin lacks a file, upstream adds it, merge, restore): without rm -rf first, the restore step produces a zero-diff commit and the new file is still there; with it, the file is correctly staged for deletion and the restore actually restores.
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
#58's restoration step (`git checkout origin/main -- .github/workflows`) looked right but doesn't actually work for the case that caused the original bug. Verified by manually triggering the workflow after #58 merged — it failed again, identical rejection:
```
! [remote rejected] sync/upstream-latest -> sync/upstream-latest (refusing to allow a GitHub App to create or update workflow `.github/workflows/integration_tests.yml` without `workflows` permission)
```
Root cause
`git checkout -- ` only overwrites paths that already exist in ``. It does not delete a file that's present in the working tree/index but absent from `` — so a brand-new workflow file the merge just pulled in from upstream (which `origin/main` never had) survives the "restore" step untouched, and the push still gets rejected for it. This is exactly the upstream-added-a-new-workflow-file scenario that caused the bug in the first place.
Fix
`rm -rf .github/workflows` before the restore checkout, then `git add -A` to also stage the deletion (the checkout alone doesn't unstage a path that's absent from the target ref).
Verification
Reproduced the exact scenario in a throwaway local git sandbox (origin lacks a file, upstream adds a new one, merge, restore):
Also applies the identical fix to `mlx-swift`'s sibling workflow (PR here), which has the same latent bug — it just hasn't hit it yet because upstream mlx-swift hasn't added a new workflow file recently.
Test plan