fix: exempt the Tauri icons from an LFS filter this repo does not use - #186
Merged
Merged
Conversation
Coverage Diff failed on this PR:
error: Your local changes to the following files would be overwritten by checkout:
desktop/src-tauri/icons/128x128.png
desktop/src-tauri/icons/128x128@2x.png
desktop/src-tauri/icons/32x32.png
Please commit your changes or stash them before you switch branches.
Nothing modified those files. The job checks out the base ref to compare coverage,
and git refused.
.gitattributes declares `*.png filter=lfs diff=lfs merge=lfs -text` under a comment
saying these types "should only exist in GitHub Releases, never tracked in git
history". But this repo does not use LFS at all: there is no .lfsconfig, and all 32
tracked PNGs are real blobs — none is a pointer. On a runner that HAS git-lfs
installed (every GitHub-hosted runner does) the clean filter reports a tracked PNG
as locally modified, so any job that switches refs fails.
This is latent for all 32 PNGs; this PR is simply the first in a while to change
one. Exempt the Tauri icon directory, which is where it actually matters: those
files must be tracked because tauri.conf.json's bundle.icon reads them from the
working tree at build time, so "keep it in a Release instead" is not available.
Committed locally with git-lfs absent, so the blobs are genuine image data — the
Windows and macOS builds that consumed them both passed and uploaded real
artifacts, which would not be true of pointer files.
The wider question — that `filter=lfs` does not prevent anything and only breaks
checkouts when LFS is present — is left for the org-wide .gitattributes owner.
PR Checks Summary
✅ All checks passed! Ready for review. |
Security Scan Results: PASSED
|
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
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.
The bug
Any PR that changes a tracked PNG breaks
Coverage Diff:Nothing modified those files. The job checks out the base ref to measure baseline coverage, then returns — and git refuses.
.gitattributesdeclares*.png filter=lfs diff=lfs merge=lfs -text, under a comment saying these types "should only exist in GitHub Releases, never tracked in git history". But this repo does not use LFS:.lfsconfigEvery GitHub-hosted runner ships
git-lfs, so the clean filter reports a tracked PNG as locally modified, and any job that switches refs fails. This is latent for all 32 PNGs; it only surfaced now because #181 is the first PR in a while to change one.Why this has to land separately
It cannot validate itself inside the PR that needs it.
Coverage Diffspends part of its run on the base ref, where the exemption would not yet exist — so the returngit checkout -is blocked even when the head has the fix. Observed exactly that on #181: with the fix on the head only, the base checkout succeeded and the base suite ran (32,430 passed), then coming back failed.The exemption has to be on
mainfirst. This PR touches no PNG, so its ownCoverage Diffhas nothing to be blocked by.The fix
Scoped to the Tauri icon directory because that is where it is forced:
tauri.conf.json'sbundle.iconreads those files from the working tree at build time, so "keep it in a Release instead" is not an option for them.Deliberately not changed
The org-wide
*.png filter=lfsrule stays. The broader observation — thatfilter=lfsprevents nothing and only breaks checkouts when LFS is installed — belongs to whoever owns that standard file, and changing it here would quietly alter behaviour for 29 other PNGs I have not looked at.