Skip to content

DO NOT MERGE: combined check, batch b26 - #1117

Closed
jayden1711 wants to merge 7 commits into
mainfrom
combined-b26
Closed

jayden1711 wants to merge 7 commits into
mainfrom
combined-b26

Conversation

@jayden1711

Copy link
Copy Markdown
Owner

DO NOT MERGE. Combined check for batch b26: #1097 @81f4cfcc.

…1011)

Under the standard git-lfs filter, a file of any size whose first 1024 bytes
name a pointer version and that isn't the exact pointer form refuses the
commit: git-lfs reads such a file as a pointer from its first 1024 bytes and
smudges it to the object, ignoring the rest.

The git-lfs git would run (its own exec path first, then PATH) must be a
program only root can change; one the user could replace, a path entry
that depends on the folder, or none found refuses the commit.

Signed-off-by: Jayden Vasquez <jaydenvasquez1711@gmail.com>
… never refuse the side before (#1011)

The git-lfs program check ran whenever the effective config held the
standard filter, which git lfs install writes globally, so with a
user-owned git-lfs every agent commit in every checkout was refused. git
runs the filter only for files that carry it, so the check now runs only
when a file in the checkout carries filter=lfs (working tree's or index's
attributes).

The pointer-marker refusal no longer applies to the side before: it is
only subtracted from what is found, so read as its bytes it can only find
more.

Signed-off-by: Jayden Vasquez <jaydenvasquez1711@gmail.com>
…ne can bring a file under the filter (#1011)

The git-lfs program check looked at the attributes before the line ran,
but a git mv or git rm earlier in the line can move a file into a
filter=lfs pattern, move an attributes file into place, or remove a
negation. The commit plan now marks such lines (scope.moves), and the
check then always runs under the standard filter.

Signed-off-by: Jayden Vasquez <jaydenvasquez1711@gmail.com>
…he filter (#1011)

Rounds 2 and 3 checked the git-lfs program only for files that matched
filter=lfs before the line ran, and staging in the line (a deleted
negating attributes file staged by git add or commit -a) could still
bring a file under the filter afterwards. The check now runs whenever any
attributes source names filter=lfs, whether or not a path matches it:
attributes files in the working tree, the index and HEAD, info/attributes,
and the user's and system's files.

Only a git mv that names an attributes file still marks the line, since
it can make a file an attributes file; plain git mv and git rm no longer
do, and the refusal says to run the git mv in a call of its own.

Signed-off-by: Jayden Vasquez <jaydenvasquez1711@gmail.com>
…it-lfs (#1011)

Ignored attributes files, attr.tree and GIT_ATTR_SOURCE now count, a
relative core.attributesFile is read from the checkout's top, git var
failures refuse, and the git mv flag matches only attributes file names.
The index-only fixture is absent from HEAD, and new tests cover the
working-tree-only source.

Signed-off-by: Jayden Vasquez <jaydenvasquez1711@gmail.com>
…un (#1011)

A wrapper git on PATH answers `git var GIT_ATTR_*` as a failure, a silent
exit and an old git with no such variable; each test fails with its branch
removed. A real-git test keeps the no-HOME commit allowed.

The comment and changelog no longer say git runs git-lfs only for a file
under the filter, or that other checkouts commit as before: the hooks
`git lfs install` writes still run the git-lfs PATH finds (#1110).

Signed-off-by: Jayden Vasquez <jaydenvasquez1711@gmail.com>
Signed-off-by: Jayden Vasquez <jaydenvasquez1711@gmail.com>
@jayden1711 jayden1711 closed this Oct 26, 2026
@jayden1711
jayden1711 deleted the combined-b26 branch October 26, 2026 14:20
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