git-lfs/t/t-attributes.sh

98 lines
2.6 KiB
Bash
Raw Normal View History

#!/usr/bin/env bash
. "$(dirname "$0")/testlib.sh"
begin_test "macros"
(
set -e
reponame="$(basename "$0" ".sh")"
clone_repo "$reponame" repo
mkdir dir
printf '[attr]lfs filter=lfs diff=lfs merge=lfs -text\n*.dat lfs\n' \
> .gitattributes
printf '[attr]lfs2 filter=lfs diff=lfs merge=lfs -text\n*.bin lfs2\n' \
> dir/.gitattributes
git add .gitattributes dir
git commit -m 'initial import'
contents="some data"
printf "$contents" > foo.dat
git add *.dat
git commit -m 'foo.dat'
assert_local_object "$(calc_oid "$contents")" 9
contents2="other data"
printf "$contents2" > dir/foo.bin
git add dir
git commit -m 'foo.bin'
refute_local_object "$(calc_oid "$contents2")"
git lfs track '*.dat' 2>&1 | tee track.log
grep '"*.dat" already supported' track.log
t/t-attributes.sh: test check top-level macro rule In commit f4b8938fd60dfb705d83a62f153acd59fe067a51 of PR #3391 the t/t-attributes.sh file was added with an initial "macros" test, and part of that test confirms that macro attribute definitions are only processed when they appear in the top-level .giattributes file in a repository. The test does confirm this in that it creates both an "lfs2" macro attribute definition and assignment of that attribute name to a file pattern in a .gitattributes file in a subdirectory, and then validates that a file matching that pattern in the subdirectory is not converted into an LFS object. The test also includes a second check of this logic in which it confirms that a "git lfs track" command for the file pattern in the subdirectory succeeds, i.e., that it does not fail because the file pattern was already assigned the normal "filter=lfs" attribute by the "lfs2" macro attribute. However, this particular check will always succeed, even if macro attribute definitions like the "lfs2" one are incorrectly accepted from .gitattributes files other than the top-level one. This is because the "git lfs track" command is run in the top-level directory and only sets a pattern that includes the subdirectory in its path (i.e., "dir/*.bin"). This will succeed regardless of whether the "*.bin" pattern is assigned to LFS attributes in the dir/.gitattributes file. We therefore make this second check more sensitive to potential future regressions by running the "git lfs track" command in the subdirectory. Now if the macro definition in the .gitattributes file in that directory is (incorrectly) read as a valid definition, and the check which tests that the file in the subdirectory has not been converted into an LFS object is skipped, then this second check fails as expected.
2022-11-04 04:24:50 +00:00
cd dir
git lfs track '*.bin' 2>&1 | tee track.log
! grep '"*.bin" already supported' track.log
t/t-{attributes,fsck}.sh: test macro support In commit f4b8938fd60dfb705d83a62f153acd59fe067a51 of PR #3391 the t/t-attributes.sh test script was introduced with its initial "macros" test, which validates that the "git lfs track" command is able to parse macro attribute definitions in the top-level .gitattributes file and resolve references to those macros in the same file. It also confirms that the command does not accept macro definitions in .gitattributes files in subdirectories, as Git does not accept these either. However, Git does resolve macro attribute references from .gitattributes files in subdirectories, so long as they refer to macro attributes defined in the top-level .gitattributes (or one of the other files where definitions are accepted, such as the .git/info/attributes file). But the "git lfs track" command at present does not resolve such references consistently because it sorts the attributes files by path length and then processes them strictly in that order, from longest to shortest. Thus references to macro attributes defined in the top-level .gitattributes file from other attributes files never succeed because the top-level file is always parsed last (except for the global and system attributes files). We therefore add a note to this effect in the "macros" test to explain why we do not test valid macro attribute references in a .gitattributes file in a subdirectory. (There is also an inconsistency in how "git lfs track" handles references to macro attributes defined in the .git/info/attributes file, because if the references appear in .gitattributes files whose full file path in the repository is longer than ".git/info/attributes", then the references are not resolved as these files are parsed before the .git/info/attributes one, whereas references from other .gitattributes files are resolved.) Separately, in commit 608bc8d53efe0bfc789dae4b934e18af69ebd8e5 of PR #4525 support for scanning the repository contents using the output of the "git ls-tree" command was added to help enable the "git lfs fsck" to search for invalid Git LFS pointer files. The GitScanner.ScanRefByTree() method invokes a chain of functions, of which catFileBatchTreeForPointers() reads Git blob metadata and examines each blob in turn to see if it is a Git LFS pointer or a .gitattributes file, and if it is the latter it reads and parses its contents, including macro attribute definitions if the file is the top-level .gitattributes file. We therefore add a "fsck detects invalid pointers with macro patterns" test to the t/t-fsck.sh test script which validates the ability of the "git lfs fsck" command to report as invalid pointers any files matching patterns with a "filter=lfs" attribute defined by reference to a macro attribute defined in the top-level .gitattributes file. To do this we refactor the setup_invalid_pointers() helper function so that we can reuse some of its code in a new, smaller function that just creates invalid pointers. However, we also add a note explaining that we can not yet test this behaviour with a .gitattributes file whose parent directory sorts before the top-level .gitattributes one in the output from "git ls-tree". Because that command outputs its results sorted by filepath, a file such as .dir/.gitattributes will be listed before the top-level .gitattributes file, and so any macro attribute references from the .dir/.gitattributes file to macro attributes defined in the top-level .gitattributes file will not be resolved in the way that Git resolves them. For now we defer resolution of this issue and the ones described regarding the "git lfs track" command to the future.
2022-11-07 16:42:04 +00:00
# NOTE: At present we do not test that "git lfs track" reports
# "already supported" when it finds a pattern in a subdirectory's
# .gitattributes file which references a macro attribute in
# the top-level .gitattributes file that sets "filter=lfs".
# This is because, while "git check-attr" resolves macro references
# from a file such as dir/.gitattributes to .gitattributess,
# "git lfs track" only resolves macro references as it reads these
# files in depth-first order, so unlike Git it does not expand an
# "lfs" reference to "filter=lfs" if it appears in dir/.gitattributes.
)
end_test
begin_test "macros with HOME"
(
set -e
reponame="$(basename "$0" ".sh")-home"
clone_repo "$reponame" repo-home
mkdir -p "$HOME/.config/git"
printf '[attr]lfs filter=lfs diff=lfs merge=lfs -text\n*.dat lfs\n' \
> "$HOME/.config/git/attributes"
contents="some data"
printf "$contents" > foo.dat
git add *.dat
git commit -m 'foo.dat'
assert_local_object "$(calc_oid "$contents")" 9
git lfs track 2>&1 | tee track.log
grep '*.dat' track.log
)
end_test
begin_test "macros with HOME split"
(
set -e
reponame="$(basename "$0" ".sh")-home-split"
clone_repo "$reponame" repo-home-split
mkdir -p "$HOME/.config/git"
printf '[attr]lfs filter=lfs diff=lfs merge=lfs -text\n' \
> "$HOME/.config/git/attributes"
printf '*.dat lfs\n' > .gitattributes
git add .gitattributes
git commit -m 'initial import'
contents="some data"
printf "$contents" > foo.dat
git add *.dat
git commit -m 'foo.dat'
assert_local_object "$(calc_oid "$contents")" 9
git lfs track '*.dat' 2>&1 | tee track.log
grep '"*.dat" already supported' track.log
)
end_test