Skip to content

fix(repo): store the producer fixtures as the LFS pointers they declare - #3124

Open
miguel-heygen wants to merge 1 commit into
mainfrom
fix/normalize-lfs-fixtures
Open

fix(repo): store the producer fixtures as the LFS pointers they declare#3124
miguel-heygen wants to merge 1 commit into
mainfrom
fix/normalize-lfs-fixtures

Conversation

@miguel-heygen

Copy link
Copy Markdown
Collaborator

What

Store the 67 producer test fixtures that .gitattributes routes through LFS as the pointers it declares. 68 files, 201 insertions, 47,304 deletions.

Why

.gitattributes has routed packages/producer/tests/**/output/compiled.html through LFS for a while, and the largest of these fixtures are 2.6 to 3.3 MB, so that routing is correct. But only 7 of the 74 were actually stored as pointers. The other 67 sit in the pack as plain content, most likely predating the attribute.

A file marked for LFS but stored as content cannot be checked out cleanly. The filter converts it to a pointer, git sees that as a modification, and the file is permanently dirty:

Encountered 1 file(s) that should have been pointers, but weren't:
	packages/producer/tests/webm-transparency/output/compiled.html

This is not cosmetic. It blocks git restore, git rebase, and even git rebase --autostash, all of which fail with an unstaged-changes error naming files the developer never touched:

error: cannot rebase: You have unstaged changes.

git lfs fetch and git lfs checkout do not help, because there are no pointers to resolve. On a branch that needed to rebase onto main, this made a routine rebase impossible, and the failure mode gives no hint that LFS is involved.

How

git add --renormalize packages/producer/tests re-runs the filter and stores what the attribute always said it would store. No history rewrite.

The LFS objects already existed locally, so the pointers resolve immediately. Verified before committing:

$ git show :packages/producer/tests/webm-transparency/output/compiled.html | head -3
version https://git-lfs.github.com/spec/v1
oid sha256:0a58f6769219ee42b16805f01f00fb0958f4d1402e3c2fd82b19273eed14c4e5
size 2562420

$ find .git/lfs/objects -name 0a58f676...
.git/lfs/objects/0a/58/0a58f6769219ee42b16805f01f00fb0958f4d1402e3c2fd82b19273eed14c4e5

That check matters: committing pointers whose objects do not exist would leave the fixtures unresolvable and break the producer tests. All 68 staged blobs were confirmed to be pointers (pointers=68 non-pointers=0), and the push uploaded 44 MB of objects.

Test plan

  • Unit tests added/updated
  • Manual testing performed
  • Documentation updated (if applicable)

The verification for this change is the working tree itself: git status reports 0 modified files on a fresh checkout of this branch, where main reports 14 to 20 permanently dirty fixtures that no git command can clean.

No test or source file is touched. The fixture content is unchanged; only where git stores it moves.

Not covered

History still carries the original blobs, so this shrinks new checkouts rather than the pack. Rewriting history to reclaim that is a separate, far more disruptive decision.

The 7 fixtures already stored as pointers are untouched.

.gitattributes routes packages/producer/tests compiled fixtures through LFS,
and the largest are 2.6 to 3.3 MB, so that routing is right. But only 7 of
the 74 were actually stored as pointers. The other 67 were committed as plain
content, most likely predating the attribute.

A file marked for LFS but stored as content cannot be checked out cleanly:
the filter converts it to a pointer, git sees that as a modification, and the
file is permanently dirty. It fails with a should-have-been-pointers error.

That is not cosmetic. It blocks git restore, git rebase, and even rebase with
autostash, all of which fail with an unstaged-changes error naming files the
developer never touched. git lfs fetch and git lfs checkout do not help,
because there are no pointers to resolve. On one branch it made a routine
rebase onto main impossible.

Renormalizing re-runs the filter and stores what the attribute always said it
would. The LFS objects already existed locally, so the pointers resolve.

History still carries the original blobs. This fixes checkout, not the pack.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant