Disclosure: This draft was generated with AI and checked against the cited primary sources, with a separate AI editorial review. It was prepared for the FrameSprite team, which has a commercial interest in FrameSprite. Proposed examples are not executed tests unless explicitly identified as recorded fixture results.
Stage the sprite again after exporting the correction, then compare the staged revision with the reviewed file. Git stores a staging snapshot. An export saved after an earlier git add can remain outside the next commit even though your local preview shows the corrected art.
Key Takeaways
- Check staged and unstaged changes separately.
- Review the version that the commit will contain.
- Stage texture and dependent sidecars together when their contract changes.
Why the editor and commit disagree
The Git add manual states that staging captures content at that time. It does not continuously watch a PNG as the artist keeps exporting. Saving a new version changes the working file, not the already staged copy.
This creates a subtle review failure. A reviewer sees the latest texture in a local viewer, while the eventual commit contains the previous export. The situation can occur without a merge, a cache, or an image encoder bug.
Inspect both comparisons
Start with Git status to distinguish staged and unstaged changes. If the same texture appears in both categories, do not assume the staged entry is the final version. Inspect which export created each state.
The Git diff reference documents comparisons involving the working tree and index. Use the staged comparison to review what will be committed. For binary art, supplement repository status with a view of the actual staged candidate through an appropriate tool or a temporary export from the index.
Do not overwrite the only copy of the corrected master while investigating. Preserve it, identify its export settings, and then stage the intended texture. If timing, grid dimensions, or attachment data changed, stage and review those files as one delivery set.
Example: the missing boot correction
An artist stages scout/run.png, notices a boot flicker, repaints it, and exports again. The local animation now looks correct. They commit without staging the second export. The teammate receives the older boot because the first snapshot was what Git had prepared.
The diagnostic question is whether the corrected pixels exist in the commit object, not whether the artist can see them locally. Compare a fresh checkout of that commit to the saved correction. If the new pixels are absent, add a normal follow-up commit with the intended file and explain which preview should be used.
Avoid changing repository history just to hide a routine correction unless the team has a specific reason and agreement. The important outcome is a traceable delivery that everyone can obtain.
A small acceptance habit
Before requesting final art review, finish the export, inspect status, stage the delivery set, and regenerate the review preview from the candidate revision. Stop editing those files while the reviewer checks them, or clearly identify any subsequent changes requiring another look.
The handover passes when the reviewed texture and sidecars match the committed versions and no required correction remains only in the working tree. A clean status alone is insufficient if the wrong file was intentionally committed.
This is a proposed workflow based on Git's documented snapshot behavior. The boot example is illustrative, not a recorded production incident or an executed test.
Continue the workflow
Use the Is a GIF preview enough for a teammate to approve a sprite animation? for the neighboring problem. Keep the animation handoff checklist with the delivered package, and preserve its visual decisions in the game-art reference board.
Sources and editorial responsibility
Prepared by the FrameSprite Workflow Team. See the editorial method or contact the team with a reproducible correction. Sources checked 2026-10-20.
Top comments (0)