fix: rm -rf before restoring .github/workflows, preventively - #14
Merged
Merged
Conversation
This repo's upstream-sync.yml has the same latent bug just found and fixed in mlx-swift-lm's sibling workflow: git checkout <ref> -- <path> only overwrites paths that already exist in <ref>, so it silently fails to remove a brand-new workflow file upstream just added (which origin/main never had). This repo hasn't hit it yet only because upstream mlx-swift hasn't added a new workflow file recently — the same upstream org (ml-explore) adding one here is only a matter of time, and it would reproduce mlx-swift-lm's exact failure.
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
Applies the same preventive fix as mlx-swift-lm#59 to this repo's identically-structured upstream-sync.yml.
Root cause
`git checkout -- ` only overwrites paths that already exist in ``. It does not delete a file 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) would survive the restore step untouched, and the push would get rejected for it, exactly like mlx-swift-lm's sync just did.
This repo's sync has succeeded on every run so far only because upstream mlx-swift hasn't added a new workflow file recently — the bug is latent, not yet triggered, in this specific workflow.
Fix
`rm -rf .github/workflows` before the restore checkout, then `git add -A` to stage the deletion too.
Verification
Same fix, verified against the exact scenario in mlx-swift-lm#59 via a local git sandbox reproducing origin-lacks-file / upstream-adds-file / merge / restore.