Files
git/t/t6011-rev-list-with-bad-commit.sh
Junio C Hamano 41429cb4e4 t6011: fix misconversion from perl to sed
No, this is not about a quiz on regexp compatibility between Perl
and sed.

Back when cdbdc6bf (t: refactor tests depending on Perl substitution
operator, 2025-04-03) rewrote many uses of perl with sed, the general
pattern of the original scripts were

    chmod +w some_read_only_file &&
    perl -p -e "regexp to munge" some_read_only_file >some_tmp &&
    mv some_tmp some_read_only_file

persumably because the author knew that replacing some_read_only_file
with "mv" at the last step would not work without "mv -f" in some
environments (GNU seems to succeed without giving any prompt when
not running interactively, which is what happens when running t/
scripts).  Replacing perl with sed would be fine as long as sed with
updated regexp does the equivalent munging.

But one place used to use a different construct in the original:

    perl -i.bak -p -e "regexp to munge" some_read_only_file

With _no_ temporary file or "mv", "perl -i" allows you to replace a
read-only file in place.

When we replaced the use of "perl" with "sed" in the said commit,
however, because "sed -i" is not portable, we rewrote that in-place
replacement to

    sed "regexp to munge" some_read_only_file >some_tmp &&
    mv some_tmp some_read_only_file

Again, unfortunately that does not work in some environment, without
"mv -f".

We could run "mv -f" here, but we would then need to remove "chmod
+w" and have them use "mv -f" instead at all places that were
touched cdbdc6bf (t: refactor tests depending on Perl substitution
operator, 2025-04-03) to be consistent (and more concise).

For now, let's make it consistent in the other direction by mimick
the other places that made the target read-write before moving.

Speaking of portability, the outcome of using "sed" on non-text
files is unspecified, so the entire exercise of cdbdc6bf may have
needed to be reverted if people still used ancient version of
"standard compliant" sed that barfs on non-text files, but these
days we may be able to get away with "BSDs and GNU seem OK with it"
;-)  But one fix at a time.

Reported-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-05-07 08:30:17 -07:00

65 lines
1.5 KiB
Bash
Executable File

#!/bin/sh
test_description='git rev-list should notice bad commits'
. ./test-lib.sh
# Note:
# - compression level is set to zero to make "corruptions" easier to perform
# - reflog is disabled to avoid extra references which would twart the test
test_expect_success 'setup' \
'
git init &&
git config core.compression 0 &&
git config core.logallrefupdates false &&
echo "foo" > foo &&
git add foo &&
git commit -m "first commit" &&
echo "bar" > bar &&
git add bar &&
git commit -m "second commit" &&
echo "baz" > baz &&
git add baz &&
git commit -m "third commit" &&
echo "foo again" >> foo &&
git add foo &&
git commit -m "fourth commit" &&
git repack -a -f -d
'
test_expect_success 'verify number of revisions' \
'
revs=$(git rev-list --all | wc -l) &&
test $revs -eq 4 &&
first_commit=$(git rev-parse HEAD~3)
'
test_expect_success 'corrupt second commit object' '
for p in .git/objects/pack/*.pack
do
chmod +w "$p" &&
sed "s/second commit/socond commit/" "$p" >"$p.munged" &&
mv "$p.munged" "$p" ||
return 1
done &&
test_must_fail git fsck --full
'
test_expect_success 'rev-list should fail' '
test_must_fail env GIT_TEST_COMMIT_GRAPH=0 git -c core.commitGraph=false rev-list --all > /dev/null
'
test_expect_success 'git repack _MUST_ fail' \
'
test_must_fail git repack -a -f -d
'
test_expect_success 'first commit is still available' \
'
git log $first_commit
'
test_done