git-lfs/t/t-post-commit.sh
brian m. carlson a5d20de4a8
t: avoid incorrect negated commands
When `set -e` is enabled, not all commands trigger an error exit if they
return false.  For example, it's clear that commands in an `if` or
`while` statement don't cause an error if they are false.

What is less obvious, however, is that negated commands and negated
pipelines also have no effect on `set -e`.  From POSIX 1003.1-2017 (on
`sh -e`):

    When this option is on, if a simple command fails for any of the
    reasons listed in Consequences of Shell Errors or returns an exit
    status value >0, and is not part of the compound list following a
    while, until, or if keyword, and is not a part of an AND or OR list,
    and is not a pipeline preceded by the ! reserved word, then the
    shell shall immediately exit.

As such, writing something like `! grep` will never fail.  Fortunately,
we can append `&& exit 1` instead of the `!` and that will work
correctly.

To make this work, run the following command to make the code properly
check the exit status of our commands:

  git grep -l '! [a-z]' t | \
    xargs ruby -pi -e '$_.gsub!(/^(\s+)! ([a-z].*)$/, "\\1\\2 && exit 1")'

Because such a command will still have a non-zero exit status, even if
it doesn't trigger `set -e`, add a `true` if this is the last statement
in a block, so that the test exits successfully and therefore passes.
2023-02-22 14:57:29 +00:00

108 lines
2.5 KiB
Bash
Executable File

#!/usr/bin/env bash
. "$(dirname "$0")/testlib.sh"
begin_test "post-commit"
(
set -e
reponame="$(basename "$0" ".sh")"
setup_remote_repo "$reponame"
clone_repo "$reponame" "$reponame"
git lfs track --lockable "*.dat"
git lfs track "*.big" # not lockable
git add .gitattributes
git commit -m "add git attributes"
echo "Come with me" > pcfile1.dat
echo "and you'll be" > pcfile2.dat
echo "in a world" > pcfile3.big
echo "of pure imagination" > pcfile4.big
git add *.dat
git commit -m "Committed large files"
# New lockable files should have been made read-only now since not locked
refute_file_writeable pcfile1.dat
refute_file_writeable pcfile2.dat
assert_file_writeable pcfile3.big
assert_file_writeable pcfile4.big
git push -u origin main
# now lock files, then edit
git lfs lock pcfile1.dat
git lfs lock pcfile2.dat
echo "Take a look" > pcfile1.dat
echo "and you'll see" > pcfile2.dat
git add pcfile1.dat pcfile2.dat
git commit -m "Updated"
# files should remain writeable since locked
assert_file_writeable pcfile1.dat
assert_file_writeable pcfile2.dat
)
end_test
begin_test "post-commit (locked file outside of LFS)"
(
set -e
reponame="post-commit-external"
setup_remote_repo "$reponame"
clone_repo "$reponame" "$reponame"
git lfs install
# This step is intentionally done in two commits, due to a known bug bug in
# the post-checkout process LFS performs. It compares changed files from HEAD,
# which is an invalid previous state for the initial commit of a repository.
echo "*.dat lockable" > .gitattributes
git add .gitattributes
git commit -m "initial commit"
echo "hello" > a.dat
git add a.dat
assert_file_writeable a.dat
git commit -m "add a.dat"
refute_file_writeable a.dat
)
end_test
begin_test "post-commit does not enter submodules"
(
set -e
reponame="post-commit-submodules"
setup_remote_repo "$reponame"
clone_repo "$reponame" "$reponame"
git lfs track --lockable "*.dat"
git lfs track "*.big" # not lockable
git add .gitattributes
git commit -m "add git attributes"
mkdir submodule
(cd submodule && git init && echo abc >foo && git add foo && git commit -m 'foo')
git submodule add ./submodule submodule
git commit -m 'Add submodule'
echo "Come with me" > pcfile1.dat
echo "and you'll be" > pcfile2.dat
echo "in a world" > pcfile3.big
echo "of pure imagination" > pcfile4.big
git add *.dat
GIT_TRACE=1 git commit -m "Committed large files" 2>&1 | tee output
grep -E 'filepathfilter:.*submodule/foo' output && exit 1
true
)
end_test