Five files under build/hark.app/ are tracked and pushed to origin/main, including two compiled arm64 Mach-O executables.
$ git ls-files build/
build/hark.app/Contents/Info.plist 2,160 B
build/hark.app/Contents/MacOS/hark-agent 143,696 B Mach-O 64-bit executable arm64
build/hark.app/Contents/MacOS/rec 103,600 B
build/hark.app/Contents/PkgInfo 8 B
build/hark.app/Contents/_CodeSignature/CodeResources 2,421 B
They arrived in 3253032 — whose subject is [docs] Point the README at the Swift tree — so this looks accidental rather than intended.
Why .gitignore did not catch it
The ignore rule names the canonical output path only:
# Generated app bundle (rebuilt by swift/Packaging/build-app.sh).
swift/Packaging/Hark.app/
build/ is a second location a bundle can land in and is covered by no rule — git check-ignore -v build/hark.app/Contents/MacOS/hark-agent matches nothing.
Why it is worth fixing
- Every rebuild is a binary diff. The bundle is ad-hoc signed, so its cdhash changes on each build;
_CodeSignature/CodeResources changes with it. That is a permanent source of noisy, unmergeable diffs in a repo that otherwise reviews cleanly.
- A downloadable binary here is a trap for users. Anything fetched from GitHub carries
com.apple.quarantine, and this bundle is ad-hoc signed — spctl -a -vv build/hark.app reports rejected. Someone who finds it and runs it gets "damaged and can’t be opened" on a project that installs cleanly when built from source. The README (correctly) tells people to run the installers; a stale committed bundle contradicts that.
- It is ~247 KB of arm64-only binary in a source repo, and it will only grow.
Suggested fix
printf "\n# Generated app bundle (second location; see swift/Packaging/).\nbuild/\n" >> .gitignore
git rm -r --cached build/
Worth considering whether the ignore rule should match the bundle by name rather than by path (Hark.app/, hark.app/) so a third build location cannot reintroduce this.
Not a history rewrite
These are build outputs, not secrets, so removing them from HEAD is sufficient — there is no reason to rewrite published history over this. Noting it explicitly because this repo has had a scrub-and-squash before, and that precedent should not be reached for here.
Five files under
build/hark.app/are tracked and pushed toorigin/main, including two compiled arm64 Mach-O executables.They arrived in
3253032— whose subject is[docs] Point the README at the Swift tree— so this looks accidental rather than intended.Why
.gitignoredid not catch itThe ignore rule names the canonical output path only:
build/is a second location a bundle can land in and is covered by no rule —git check-ignore -v build/hark.app/Contents/MacOS/hark-agentmatches nothing.Why it is worth fixing
_CodeSignature/CodeResourceschanges with it. That is a permanent source of noisy, unmergeable diffs in a repo that otherwise reviews cleanly.com.apple.quarantine, and this bundle is ad-hoc signed —spctl -a -vv build/hark.appreportsrejected. Someone who finds it and runs it gets "damaged and can’t be opened" on a project that installs cleanly when built from source. The README (correctly) tells people to run the installers; a stale committed bundle contradicts that.Suggested fix
Worth considering whether the ignore rule should match the bundle by name rather than by path (
Hark.app/,hark.app/) so a third build location cannot reintroduce this.Not a history rewrite
These are build outputs, not secrets, so removing them from
HEADis sufficient — there is no reason to rewrite published history over this. Noting it explicitly because this repo has had a scrub-and-squash before, and that precedent should not be reached for here.