Adjust test helpers and tests related to path filtering #4960
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.
In preparing a PR to address #4945 and adding tests to ensure that issue does not recur, a number of problems with our tests, test helpers, and the implementation of the
git lfs prunecommand were exposed by the new tests and checks. These will be resolved in a series of forthcoming PRs.As preparation, we first make a number of small adjustments to our test suite, adding additional checks to the
"fsck detects invalid objects"test int/t-fsck.sh, removing whitespace and revising comments for greater clarity, and changing theassert_pointer()andrevise_pointer()test helper functions to be consistent with each other again and to apply a stricter match for file paths. We also remove one unused function from the Go codebase.This PR may be most easily reviewed commit-by-commit, mostly because the individual commit descriptions provide detailed context on each change. The key changes are:
The
assert_pointer()andrefute_pointer()test helper functions usegrepto match specific lines of output fromgit ls-tree. However, whileassert_pointer()matches with fixed patterns by usinggrep's-Foption,refute_pointer()does not. This difference was introduced in commit fc421da of PR Provide an option to track to handle paths literally #3756, so we updaterefute_pointer()to match.In a subsequent PR we will also need to ensure that the file paths we provide as arguments to these functions (specifically, to
assert_pointer()) do not match just any part of the paths output bygit ls-tree, but only at the start of the path. That is,a.binshould matcha.binbut notfoo/a.bin. Because the output fromgit ls-treeis space-separated, we prepend a space to our fixed patterns so we match against the start of the file path.This has the limitation that if a test has a file named
foo a.bin, and calls one of these functions with just the filenamea.bin, it will incorrectly match the filename with a space. However, at present only one of our tests that calls either of these functions, specifically the"track: escaped glob pattern with spaces in .gitattributes"test int/t-track.sh, has a filename with a space in it, and does not create any additional files which might be confused by that filename.In our
"fsck detects invalid objects"test of thegit lfs fsckcommand we currently only use files in the top-level directory for which we then corrupt or remove the corresponding Git LFS object files. In a subsequent PR we will add a parallel test which checks that thelfs.fetchexcludeoption is supported for this command, specifically by excluding files in a subdirectory. For the primary test, then, we want to demonstrate normal behaviour without path-based exclusions, so we add files in a subdirectory to our existing test and ensure their corruption is detected.The internal
parseLogOutputToPointers()function was used only by thelogPreviousSHAs()function and only until commit d8ca610 of PR Gitscanner callbacks master #1743 in 2016, so we remove it now.