Update tests to check prune command excludes lfs.fetchexclude paths
#4964
Conversation
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
The "prune keep unpushed" test ensures that Git LFS objects referenced by unpushed commits are always retained when the "git lfs prune" command is run. However, it does not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have not yet been pushed. Logic in the "git lfs prune" command to prune objects from files matching the "lfs.fetchexclude" filter was added in PR git-lfs#2851, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand the "prune keep unpushed" test so that its simulated commit history includes objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" until they are pushed, after which they are all pruned by the same command, even the object referenced by the new HEAD ref.
The "prune keep stashed changes", "prune keep stashed changes in index", and "prune keep stashed untracked files" tests ensure that Git LFS objects referenced by stashes are always retained when the "git lfs prune" command is run. However, they do not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern, which would otherwise be pruned regardless of their status, will be retained because they have been stashed. Logic in the "git lfs prune" command to retain objects from stashed changes was added in PR git-lfs#4209, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand these three tests so that their simulated commit histories include objects whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that all these objects are retained by "git lfs prune" when they are stashed, included when they are stashed from the index and when they are untracked files stashed with "git stash -u".
The "prune worktree" test ensures that Git LFS objects referenced by worktrees are always retained when the "git lfs prune" command is run. However, it does not at present check that objects belonging to files which match a "lfs.fetchexclude" pattern are pruned even when they are referenced by a commit at the HEAD of a worktree. Logic in the "git lfs prune" command to prune objects from files matching the "lfs.fetchexclude" filter was added in PR git-lfs#2851, and it should demonstrate this behaviour, but no checks actually confirm it. We therefore expand the "prune worktree" test so that its simulated commit history includes objects in each worktree's branch whose file path matches a path we then exclude using the "lfs.fetchexclude" filter. We then confirm that these objects are pruned by "git lfs prune", despite being referenced by the worktrees' HEAD refs.
bk2204
approved these changes
Apr 26, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Several existing tests ensure that the
git lfs prunecommand always retains Git LFS objects referenced by unpushed commits, stashes, and worktrees.However, none of these tests perform checks of the appropriate behaviour when files matching an
lfs.fetchexcludefilter option are involved. Support for pruning Git LFS objects referenced by files matching thelfs.fetchexcludefilter was added in PR #2851. (Support for retaining objects referenced by stashes was added later, in PR #4209).We therefore expand these tests to check for the expected behaviour, which varies depending on the specific case.
For Git LFS objects referenced only by files in unpushed commits or any type of stash (normal, index, or untracked), we now confirm that even if the files' names match a pattern in
lfs.fetchexclude, we still retain the objects locally whengit lfs pruneis run.For Git LFS objects referenced only by files in a commit at the
HEADof a worktree, we now confirm that if the files' names match a pattern inlfs.fetchexclude, then the objects are pruned locally whengit lfs pruneis run. This matches how similar files' objects are pruned even if they are referenced by a regular working tree'sHEADcommit.It may be advantageous to review this PR commit-by-commit as each commit's description provides additional context and details.
Note that we explicitly use a
gitattributes(5)-compatible form of pattern match (i.e.,/foo/**) for thelfs.fetchexcludeoptions in these changes because otherwise we will see failures as per #4945. When that issue is addressed in a future PR we will revise these tests to use the/foopattern match form in order to demonstrate thatgitignore(5)-style matching is being performed./cc @larsxschneider as author of #2851.