mirrors/git
0
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-28 20:44:04 +08:00
Code Issues Packages Projects Releases Wiki Activity
11c2177f2c
git/t/t1450-fsck.sh

457 lines
13 KiB
Bash
Raw Normal View History

fsck: HEAD is part of refs By default we looked at all refs but not HEAD. The only thing that made fsck not lose sight of commits that are only reachable from a detached HEAD was the reflog for the HEAD. This fixes it, with a new test. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-30 16:33:00 +08:00
#!/bin/sh
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
test_description='git fsck random collection of tests
* (HEAD) B
* (master) A
'
fsck: HEAD is part of refs By default we looked at all refs but not HEAD. The only thing that made fsck not lose sight of commits that are only reachable from a detached HEAD was the reflog for the HEAD. This fixes it, with a new test. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-30 16:33:00 +08:00
. ./test-lib.sh
test_expect_success setup '
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
git config gc.auto 0 &&
fsck: fix bogus commit header check daae1922 (fsck: check ident lines in commit objects, 2010-04-24) taught fsck to expect commit objects to have the form tree <object name> <parents> author <valid ident string> committer <valid ident string> log message The check is overly strict: for example, it errors out with the message “expected blank line” for perfectly valid commits with an "encoding ISO-8859-1" line. Later it might make sense to teach fsck about the rest of the header and warn about unrecognized header lines, but for simplicity, let’s accept arbitrary trailing lines for now. Reported-by: Tuncer Ayaz <tuncer.ayaz@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-27 05:50:34 +08:00
git config i18n.commitencoding ISO-8859-1 &&
fsck: HEAD is part of refs By default we looked at all refs but not HEAD. The only thing that made fsck not lose sight of commits that are only reachable from a detached HEAD was the reflog for the HEAD. This fixes it, with a new test. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-30 16:33:00 +08:00
test_commit A fileA one &&
fsck: fix bogus commit header check daae1922 (fsck: check ident lines in commit objects, 2010-04-24) taught fsck to expect commit objects to have the form tree <object name> <parents> author <valid ident string> committer <valid ident string> log message The check is overly strict: for example, it errors out with the message “expected blank line” for perfectly valid commits with an "encoding ISO-8859-1" line. Later it might make sense to teach fsck about the rest of the header and warn about unrecognized header lines, but for simplicity, let’s accept arbitrary trailing lines for now. Reported-by: Tuncer Ayaz <tuncer.ayaz@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-27 05:50:34 +08:00
git config --unset i18n.commitencoding &&
fsck: HEAD is part of refs By default we looked at all refs but not HEAD. The only thing that made fsck not lose sight of commits that are only reachable from a detached HEAD was the reflog for the HEAD. This fixes it, with a new test. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-30 16:33:00 +08:00
git checkout HEAD^0 &&
test_commit B fileB two &&
git tag -d A B &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
git reflog expire --expire=now --all &&
>empty
fsck: HEAD is part of refs By default we looked at all refs but not HEAD. The only thing that made fsck not lose sight of commits that are only reachable from a detached HEAD was the reflog for the HEAD. This fixes it, with a new test. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-30 16:33:00 +08:00
'
fsck: check loose objects from alternate object stores by default "git fsck" used to validate only loose objects that are local and nothing else by default. This is not just too little when a repository is borrowing objects from other object stores, but also caused the connectivity check to mistakenly declare loose objects borrowed from them to be missing. The rationale behind the default mode that validates only loose objects is because these objects are still young and more unlikely to have been pushed to other repositories yet. That holds for loose objects borrowed from alternate object stores as well. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-30 16:50:54 +08:00
test_expect_success 'loose objects borrowed from alternate are not missing' '
mkdir another &&
(
cd another &&
git init &&
echo ../../../.git/objects >.git/objects/info/alternates &&
test_commit C fileC one &&
fsck: --no-dangling omits "dangling object" information The default output from "fsck" is often overwhelmed by informational message on dangling objects, especially if you do not repack often, and a real error can easily be buried. Add "--no-dangling" option to omit them, and update the user manual to demonstrate its use. Based on a patch by Clemens Buchacher, but reverted the part to change the default to --no-dangling, which is unsuitable for the first patch. The usual three-step procedure to break the backward compatibility over time needs to happen on top of this, if we were to go in that direction. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-29 06:55:39 +08:00
git fsck --no-dangling >../actual 2>&1
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
) &&
test_cmp empty actual
fsck: check loose objects from alternate object stores by default "git fsck" used to validate only loose objects that are local and nothing else by default. This is not just too little when a repository is borrowing objects from other object stores, but also caused the connectivity check to mistakenly declare loose objects borrowed from them to be missing. The rationale behind the default mode that validates only loose objects is because these objects are still young and more unlikely to have been pushed to other repositories yet. That holds for loose objects borrowed from alternate object stores as well. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-30 16:50:54 +08:00
'
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
test_expect_success 'HEAD is part of refs, valid objects appear valid' '
git fsck >actual 2>&1 &&
test_cmp empty actual
fsck: fix bogus commit header check daae1922 (fsck: check ident lines in commit objects, 2010-04-24) taught fsck to expect commit objects to have the form tree <object name> <parents> author <valid ident string> committer <valid ident string> log message The check is overly strict: for example, it errors out with the message “expected blank line” for perfectly valid commits with an "encoding ISO-8859-1" line. Later it might make sense to teach fsck about the rest of the header and warn about unrecognized header lines, but for simplicity, let’s accept arbitrary trailing lines for now. Reported-by: Tuncer Ayaz <tuncer.ayaz@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-27 05:50:34 +08:00
'
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
# Corruption tests follow. Make sure to remove all traces of the
# specific corruption you test afterwards, lest a later test trip over
# it.
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
test_expect_success 'setup: helpers for corruption tests' '
sha1_file() {
echo "$*" | sed "s#..#.git/objects/&/#"
} &&
remove_object() {
file=$(sha1_file "$*") &&
test -e "$file" &&
rm -f "$file"
}
'
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
test_expect_success 'object with bad sha1' '
sha=$(echo blob | git hash-object -w --stdin) &&
old=$(echo $sha | sed "s+^..+&/+") &&
new=$(dirname $old)/ffffffffffffffffffffffffffffffffffffff &&
tests: add missing && Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-31 09:46:54 +08:00
sha="$(dirname $new)$(basename $new)" &&
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
mv .git/objects/$old .git/objects/$new &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
test_when_finished "remove_object $sha" &&
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
git update-index --add --cacheinfo 100644 $sha foo &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
test_when_finished "git read-tree -u --reset HEAD" &&
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
tree=$(git write-tree) &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
test_when_finished "remove_object $tree" &&
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
cmt=$(echo bogus | git commit-tree $tree) &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
test_when_finished "remove_object $cmt" &&
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
git update-ref refs/heads/bogus $cmt &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
test_when_finished "git update-ref -d refs/heads/bogus" &&
fsck: exit with non-zero status upon error from fsck_obj() Upon finding a corrupt loose object, we forgot to note the error to signal it with the exit status of the entire process. [jc: adjusted t1450 and added another test] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-30 04:31:46 +08:00
test_must_fail git fsck 2>out &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
cat out &&
grep "$sha.*corrupt" out
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
'
test_expect_success 'branch pointing to non-commit' '
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
git rev-parse HEAD^{tree} >.git/refs/heads/invalid &&
test_when_finished "git update-ref -d refs/heads/invalid" &&
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
git fsck 2>out &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
cat out &&
grep "not a commit" out
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
'
fsck: check ident lines in commit objects Check that email addresses do not contain <, >, or newline so they can be quickly scanned without trouble. The copy() function in ident.c already ensures that ordinary git commands will not write email addresses without this property. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-25 00:06:08 +08:00
test_expect_success 'email without @ is okay' '
git cat-file commit HEAD >basis &&
sed "s/@/AT/" basis >okay &&
new=$(git hash-object -t commit -w --stdin <okay) &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
test_when_finished "remove_object $new" &&
fsck: check ident lines in commit objects Check that email addresses do not contain <, >, or newline so they can be quickly scanned without trouble. The copy() function in ident.c already ensures that ordinary git commands will not write email addresses without this property. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-25 00:06:08 +08:00
git update-ref refs/heads/bogus "$new" &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
test_when_finished "git update-ref -d refs/heads/bogus" &&
fsck: check ident lines in commit objects Check that email addresses do not contain <, >, or newline so they can be quickly scanned without trouble. The copy() function in ident.c already ensures that ordinary git commands will not write email addresses without this property. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-25 00:06:08 +08:00
git fsck 2>out &&
cat out &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
! grep "commit $new" out
fsck: check ident lines in commit objects Check that email addresses do not contain <, >, or newline so they can be quickly scanned without trouble. The copy() function in ident.c already ensures that ordinary git commands will not write email addresses without this property. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-25 00:06:08 +08:00
'
test_expect_success 'email with embedded > is not okay' '
git cat-file commit HEAD >basis &&
sed "s/@[a-z]/&>/" basis >bad-email &&
new=$(git hash-object -t commit -w --stdin <bad-email) &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
test_when_finished "remove_object $new" &&
fsck: check ident lines in commit objects Check that email addresses do not contain <, >, or newline so they can be quickly scanned without trouble. The copy() function in ident.c already ensures that ordinary git commands will not write email addresses without this property. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-25 00:06:08 +08:00
git update-ref refs/heads/bogus "$new" &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
test_when_finished "git update-ref -d refs/heads/bogus" &&
fsck: exit with non-zero status upon error from fsck_obj() Upon finding a corrupt loose object, we forgot to note the error to signal it with the exit status of the entire process. [jc: adjusted t1450 and added another test] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-30 04:31:46 +08:00
test_must_fail git fsck 2>out &&
fsck: check ident lines in commit objects Check that email addresses do not contain <, >, or newline so they can be quickly scanned without trouble. The copy() function in ident.c already ensures that ordinary git commands will not write email addresses without this property. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-25 00:06:08 +08:00
cat out &&
grep "error in commit $new" out
'
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
fsck: improve committer/author check fsck allows a name with > character in it like "name> <email>". Also for "name email>" fsck says "missing space before email". More precisely, it seeks for a first '<', checks that ' ' preceeds it. Then seeks to '<' or '>' and checks that it is the '>'. Missing space is reported if either '<' is not found or it's not preceeded with ' '. Change it to following. Seek to '<' or '>', check that it is '<' and is preceeded with ' '. Seek to '<' or '>' and check that it is '>'. So now "name> <email>" is rejected as "bad name". More strict name check is the only change in what is accepted. Report 'missing space' only if '<' is found and is not preceeded with a space. Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11 18:21:10 +08:00
test_expect_success 'missing < email delimiter is reported nicely' '
fsck: add a few committer name tests fsck reports "missing space before <email>" for committer string equal to "name email>" or to "". It'd be nicer to say "missing email" for the second string and "name is bad" (has > in it) for the first one. Add a failing test for these messages. For "name> <email>" no error is reported. Looks like a bug, so add such a failing test." Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11 18:21:09 +08:00
git cat-file commit HEAD >basis &&
sed "s/<//" basis >bad-email-2 &&
new=$(git hash-object -t commit -w --stdin <bad-email-2) &&
test_when_finished "remove_object $new" &&
git update-ref refs/heads/bogus "$new" &&
test_when_finished "git update-ref -d refs/heads/bogus" &&
fsck: exit with non-zero status upon error from fsck_obj() Upon finding a corrupt loose object, we forgot to note the error to signal it with the exit status of the entire process. [jc: adjusted t1450 and added another test] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-30 04:31:46 +08:00
test_must_fail git fsck 2>out &&
fsck: add a few committer name tests fsck reports "missing space before <email>" for committer string equal to "name email>" or to "". It'd be nicer to say "missing email" for the second string and "name is bad" (has > in it) for the first one. Add a failing test for these messages. For "name> <email>" no error is reported. Looks like a bug, so add such a failing test." Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11 18:21:09 +08:00
cat out &&
grep "error in commit $new.* - bad name" out
'
fsck: improve committer/author check fsck allows a name with > character in it like "name> <email>". Also for "name email>" fsck says "missing space before email". More precisely, it seeks for a first '<', checks that ' ' preceeds it. Then seeks to '<' or '>' and checks that it is the '>'. Missing space is reported if either '<' is not found or it's not preceeded with ' '. Change it to following. Seek to '<' or '>', check that it is '<' and is preceeded with ' '. Seek to '<' or '>' and check that it is '>'. So now "name> <email>" is rejected as "bad name". More strict name check is the only change in what is accepted. Report 'missing space' only if '<' is found and is not preceeded with a space. Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11 18:21:10 +08:00
test_expect_success 'missing email is reported nicely' '
fsck: add a few committer name tests fsck reports "missing space before <email>" for committer string equal to "name email>" or to "". It'd be nicer to say "missing email" for the second string and "name is bad" (has > in it) for the first one. Add a failing test for these messages. For "name> <email>" no error is reported. Looks like a bug, so add such a failing test." Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11 18:21:09 +08:00
git cat-file commit HEAD >basis &&
sed "s/[a-z]* <[^>]*>//" basis >bad-email-3 &&
new=$(git hash-object -t commit -w --stdin <bad-email-3) &&
test_when_finished "remove_object $new" &&
git update-ref refs/heads/bogus "$new" &&
test_when_finished "git update-ref -d refs/heads/bogus" &&
fsck: exit with non-zero status upon error from fsck_obj() Upon finding a corrupt loose object, we forgot to note the error to signal it with the exit status of the entire process. [jc: adjusted t1450 and added another test] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-30 04:31:46 +08:00
test_must_fail git fsck 2>out &&
fsck: add a few committer name tests fsck reports "missing space before <email>" for committer string equal to "name email>" or to "". It'd be nicer to say "missing email" for the second string and "name is bad" (has > in it) for the first one. Add a failing test for these messages. For "name> <email>" no error is reported. Looks like a bug, so add such a failing test." Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11 18:21:09 +08:00
cat out &&
grep "error in commit $new.* - missing email" out
'
fsck: improve committer/author check fsck allows a name with > character in it like "name> <email>". Also for "name email>" fsck says "missing space before email". More precisely, it seeks for a first '<', checks that ' ' preceeds it. Then seeks to '<' or '>' and checks that it is the '>'. Missing space is reported if either '<' is not found or it's not preceeded with ' '. Change it to following. Seek to '<' or '>', check that it is '<' and is preceeded with ' '. Seek to '<' or '>' and check that it is '>'. So now "name> <email>" is rejected as "bad name". More strict name check is the only change in what is accepted. Report 'missing space' only if '<' is found and is not preceeded with a space. Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11 18:21:10 +08:00
test_expect_success '> in name is reported' '
fsck: add a few committer name tests fsck reports "missing space before <email>" for committer string equal to "name email>" or to "". It'd be nicer to say "missing email" for the second string and "name is bad" (has > in it) for the first one. Add a failing test for these messages. For "name> <email>" no error is reported. Looks like a bug, so add such a failing test." Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11 18:21:09 +08:00
git cat-file commit HEAD >basis &&
sed "s/ </> </" basis >bad-email-4 &&
new=$(git hash-object -t commit -w --stdin <bad-email-4) &&
test_when_finished "remove_object $new" &&
git update-ref refs/heads/bogus "$new" &&
test_when_finished "git update-ref -d refs/heads/bogus" &&
fsck: exit with non-zero status upon error from fsck_obj() Upon finding a corrupt loose object, we forgot to note the error to signal it with the exit status of the entire process. [jc: adjusted t1450 and added another test] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-30 04:31:46 +08:00
test_must_fail git fsck 2>out &&
fsck: add a few committer name tests fsck reports "missing space before <email>" for committer string equal to "name email>" or to "". It'd be nicer to say "missing email" for the second string and "name is bad" (has > in it) for the first one. Add a failing test for these messages. For "name> <email>" no error is reported. Looks like a bug, so add such a failing test." Signed-off-by: Dmitry Ivankov <divanorama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11 18:21:09 +08:00
cat out &&
grep "error in commit $new" out
'
fsck: report integer overflow in author timestamps When we check commit objects, we complain if commit->date is ULONG_MAX, which is an indication that we saw integer overflow when parsing it. However, we do not do any check at all for author lines, which also contain a timestamp. Let's actually check the timestamps on each ident line with strtoul. This catches both author and committer lines, and we can get rid of the now-redundant commit->date check. Note that like the existing check, we compare only against ULONG_MAX. Now that we are calling strtoul at the site of the check, we could be slightly more careful and also check that errno is set to ERANGE. However, this will make further refactoring in future patches a little harder, and it doesn't really matter in practice. For 32-bit systems, one would have to create a commit at the exact wrong second in 2038. But by the time we get close to that, all systems will hopefully have moved to 64-bit (and if they haven't, they have a real problem one second later). For 64-bit systems, by the time we get close to ULONG_MAX, all systems will hopefully have been consumed in the fiery wrath of our expanding Sun. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24 15:39:04 +08:00
# date is 2^64 + 1
test_expect_success 'integer overflow in timestamps is reported' '
git cat-file commit HEAD >basis &&
sed "s/^\\(author .*>\\) [0-9]*/\\1 18446744073709551617/" \
<basis >bad-timestamp &&
new=$(git hash-object -t commit -w --stdin <bad-timestamp) &&
test_when_finished "remove_object $new" &&
git update-ref refs/heads/bogus "$new" &&
test_when_finished "git update-ref -d refs/heads/bogus" &&
fsck: exit with non-zero status upon error from fsck_obj() Upon finding a corrupt loose object, we forgot to note the error to signal it with the exit status of the entire process. [jc: adjusted t1450 and added another test] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-30 04:31:46 +08:00
test_must_fail git fsck 2>out &&
fsck: report integer overflow in author timestamps When we check commit objects, we complain if commit->date is ULONG_MAX, which is an indication that we saw integer overflow when parsing it. However, we do not do any check at all for author lines, which also contain a timestamp. Let's actually check the timestamps on each ident line with strtoul. This catches both author and committer lines, and we can get rid of the now-redundant commit->date check. Note that like the existing check, we compare only against ULONG_MAX. Now that we are calling strtoul at the site of the check, we could be slightly more careful and also check that errno is set to ERANGE. However, this will make further refactoring in future patches a little harder, and it doesn't really matter in practice. For 32-bit systems, one would have to create a commit at the exact wrong second in 2038. But by the time we get close to that, all systems will hopefully have moved to 64-bit (and if they haven't, they have a real problem one second later). For 64-bit systems, by the time we get close to ULONG_MAX, all systems will hopefully have been consumed in the fiery wrath of our expanding Sun. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24 15:39:04 +08:00
cat out &&
grep "error in commit $new.*integer overflow" out
'
fsck: exit with non-zero status upon error from fsck_obj() Upon finding a corrupt loose object, we forgot to note the error to signal it with the exit status of the entire process. [jc: adjusted t1450 and added another test] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-30 04:31:46 +08:00
test_expect_success 'malformatted tree object' '
test_when_finished "git update-ref -d refs/tags/wrong" &&
test_when_finished "remove_object \$T" &&
T=$(
GIT_INDEX_FILE=test-index &&
export GIT_INDEX_FILE &&
rm -f test-index &&
>x &&
git add x &&
T=$(git write-tree) &&
(
git cat-file tree $T &&
git cat-file tree $T
) |
git hash-object -w -t tree --stdin
) &&
test_must_fail git fsck 2>out &&
grep "error in tree .*contains duplicate file entries" out
'
t1450: fix testcases that were wrongly expecting failure Almost exactly a year ago in 02a6552 (Test fsck a bit harder), I introduced two testcases that were expecting failure. However, the only bug was that the testcases wrote *blobs* because I forgot to pass -t tag to hash-object. Fix this, and then adjust the rest of the test to properly check the result. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-20 08:18:44 +08:00
test_expect_success 'tag pointing to nonexistent' '
tests: add missing && Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-31 09:46:54 +08:00
cat >invalid-tag <<-\EOF &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
object ffffffffffffffffffffffffffffffffffffffff
type commit
tag invalid
tagger T A Gger <tagger@example.com> 1234567890 -0000
This is an invalid tag.
EOF
tag=$(git hash-object -t tag -w --stdin <invalid-tag) &&
test_when_finished "remove_object $tag" &&
echo $tag >.git/refs/tags/invalid &&
test_when_finished "git update-ref -d refs/tags/invalid" &&
t1450: fix testcases that were wrongly expecting failure Almost exactly a year ago in 02a6552 (Test fsck a bit harder), I introduced two testcases that were expecting failure. However, the only bug was that the testcases wrote *blobs* because I forgot to pass -t tag to hash-object. Fix this, and then adjust the rest of the test to properly check the result. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-20 08:18:44 +08:00
test_must_fail git fsck --tags >out &&
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
cat out &&
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
grep "broken link" out
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
'
t1450: fix testcases that were wrongly expecting failure Almost exactly a year ago in 02a6552 (Test fsck a bit harder), I introduced two testcases that were expecting failure. However, the only bug was that the testcases wrote *blobs* because I forgot to pass -t tag to hash-object. Fix this, and then adjust the rest of the test to properly check the result. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-20 08:18:44 +08:00
test_expect_success 'tag pointing to something else than its type' '
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
sha=$(echo blob | git hash-object -w --stdin) &&
test_when_finished "remove_object $sha" &&
cat >wrong-tag <<-EOF &&
object $sha
type commit
tag wrong
tagger T A Gger <tagger@example.com> 1234567890 -0000
This is an invalid tag.
EOF
tag=$(git hash-object -t tag -w --stdin <wrong-tag) &&
test_when_finished "remove_object $tag" &&
echo $tag >.git/refs/tags/wrong &&
test_when_finished "git update-ref -d refs/tags/wrong" &&
t1450: the order the objects are checked is undefined When a tag T points at an object X that is of a type that is different from what the tag records as, fsck should report it as an error. However, depending on the order X and T are checked individually, the actual error message can be different. If X is checked first, fsck remembers X's type and then when it checks T, it notices that T records X as a wrong type (i.e. the complaint is about a broken tag T). If T is checked first, on the other hand, fsck remembers that we need to verify X is of the type tag records, and when it later checks X, it notices that X is of a wrong type (i.e. the complaint is about a broken object X). The important thing is that fsck notices such an error and diagnoses the issue on object X, but the test was expecting that we happen to check objects in the order to make us detect issues with tag T, not with object X. Remove this unwarranted assumption. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-03 06:08:16 +08:00
test_must_fail git fsck --tags
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
'
Add regression tests for stricter tag fsck'ing The intent of the new test case is to catch general breakages in the fsck_tag() function, not so much to test it extensively, trying to strike the proper balance between thoroughness and speed. While it *would* have been nice to test the code path where fsck_object() encounters an invalid tag object, this is not possible using git fsck: tag objects are parsed already before fsck'ing (and the parser already fails upon such objects). Even worse: we would not even be able write out invalid tag objects because git hash-object parses those objects, too, unless we resorted to really ugly hacks such as using something like this in the unit tests (essentially depending on Perl *and* Compress::Zlib): hash_invalid_object () { contents="$(printf '%s %d\0%s' "$1" ${#2} "$2")" && sha1=$(echo "$contents" | test-sha1) && suffix=${sha1#??} && mkdir -p .git/objects/${sha1%$suffix} && echo "$contents" | perl -MCompress::Zlib -e 'undef $/; print compress(<>)' \ > .git/objects/${sha1%$suffix}/$suffix && echo $sha1 } Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-11 22:26:41 +08:00
test_expect_success 'tag with incorrect tag name & missing tagger' '
sha=$(git rev-parse HEAD) &&
cat >wrong-tag <<-EOF &&
object $sha
type commit
tag wrong name format
This is an invalid tag.
EOF
tag=$(git hash-object -t tag -w --stdin <wrong-tag) &&
test_when_finished "remove_object $tag" &&
echo $tag >.git/refs/tags/wrong &&
test_when_finished "git update-ref -d refs/tags/wrong" &&
git fsck --tags 2>out &&
fsck: properly bound "invalid tag name" error message When we detect an invalid tag-name header in a tag object, like, "tag foo bar\n", we feed the pointer starting at "foo bar" to a printf "%s" formatter. This shows the name, as we want, but then it keeps printing the rest of the tag buffer, rather than stopping at the end of the line. Our tests did not notice because they look only for the matching line, but the bug is that we print much more than we wanted to. So we also adjust the test to be more exact. Note that when fscking tags with "index-pack --strict", this is even worse. index-pack does not add a trailing NUL-terminator after the object, so we may actually read past the buffer and print uninitialized memory. Running t5302 with valgrind does notice the bug for that reason. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-08 13:48:13 +08:00
cat >expect <<-EOF &&
fsck: report the ID of the error/warning Some repositories written by legacy code have objects with non-fatal fsck issues. To allow the user to ignore those issues, let's print out the ID (e.g. when encountering "missingEmail", the user might want to call `git config --add receive.fsck.missingEmail=warn`). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-22 23:25:52 +08:00
warning in tag $tag: badTagName: invalid '\''tag'\'' name: wrong name format
warning in tag $tag: missingTaggerEntry: invalid format - expected '\''tagger'\'' line
fsck: properly bound "invalid tag name" error message When we detect an invalid tag-name header in a tag object, like, "tag foo bar\n", we feed the pointer starting at "foo bar" to a printf "%s" formatter. This shows the name, as we want, but then it keeps printing the rest of the tag buffer, rather than stopping at the end of the line. Our tests did not notice because they look only for the matching line, but the bug is that we print much more than we wanted to. So we also adjust the test to be more exact. Note that when fscking tags with "index-pack --strict", this is even worse. index-pack does not add a trailing NUL-terminator after the object, so we may actually read past the buffer and print uninitialized memory. Running t5302 with valgrind does notice the bug for that reason. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-08 13:48:13 +08:00
EOF
test_cmp expect out
Add regression tests for stricter tag fsck'ing The intent of the new test case is to catch general breakages in the fsck_tag() function, not so much to test it extensively, trying to strike the proper balance between thoroughness and speed. While it *would* have been nice to test the code path where fsck_object() encounters an invalid tag object, this is not possible using git fsck: tag objects are parsed already before fsck'ing (and the parser already fails upon such objects). Even worse: we would not even be able write out invalid tag objects because git hash-object parses those objects, too, unless we resorted to really ugly hacks such as using something like this in the unit tests (essentially depending on Perl *and* Compress::Zlib): hash_invalid_object () { contents="$(printf '%s %d\0%s' "$1" ${#2} "$2")" && sha1=$(echo "$contents" | test-sha1) && suffix=${sha1#??} && mkdir -p .git/objects/${sha1%$suffix} && echo "$contents" | perl -MCompress::Zlib -e 'undef $/; print compress(<>)' \ > .git/objects/${sha1%$suffix}/$suffix && echo $sha1 } Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-11 22:26:41 +08:00
'
t1450: make sure fsck detects a malformed tagger line With "hash-object --literally", write a tag object that is not supposed to pass one of the new checks added to "fsck", and make sure that the new check catches the breakage. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 05:16:36 +08:00
test_expect_success 'tag with bad tagger' '
sha=$(git rev-parse HEAD) &&
cat >wrong-tag <<-EOF &&
object $sha
type commit
tag not-quite-wrong
tagger Bad Tagger Name
This is an invalid tag.
EOF
tag=$(git hash-object --literally -t tag -w --stdin <wrong-tag) &&
test_when_finished "remove_object $tag" &&
echo $tag >.git/refs/tags/wrong &&
test_when_finished "git update-ref -d refs/tags/wrong" &&
test_must_fail git fsck --tags 2>out &&
grep "error in tag .*: invalid author/committer" out
'
t1450 (fsck): remove dangling objects The fsck test is generally careful to remove the corrupt objects it inserts, but dangling objects are left behind due to some typos and omissions. It is better to clean up more completely, to simplify the addition of later tests. So: - guard setup and cleanup with test_expect_success to catch typos and errors; - check both stdout and stderr when checking for empty fsck output; - use test_cmp empty file in place of test $(wc -l <file) = 0, for better debugging output when running tests with -v; - add a remove_object () helper and use it to replace broken object removal code that forgot about the fanout in .git/objects; - disable gc.auto, to avoid tripping up object removal if the number of objects ever reaches that threshold. - use test_when_finished to ensure cleanup tasks are run and succeed when tests fail; - add a new final test that no breakage or dangling objects was left behind. While at it, add a brief description to test_description of the history that is expected to persist between tests. Part of a campaign to clean up subshell usage in tests. Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-07 09:47:07 +08:00
test_expect_success 'cleaned up' '
git fsck >actual 2>&1 &&
test_cmp empty actual
'
Test fsck a bit harder git-fsck, of all tools, has very few tests. This adds some more: * a corrupted object; * a branch pointing to a non-commit; * a tag pointing to a nonexistent object; * and a tag pointing to an object of a type other than what the tag itself claims. Only the first two are caught. At least the third probably should, too, but currently slips through. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 19:13:39 +08:00
git rev-list: fix invalid typecast git rev-list passes rev_list_info, not rev_list objects. Without this fix, rev-list enables or disables the --verify-objects option depending on a read from an undefined memory location. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-14 04:17:11 +08:00
test_expect_success 'rev-list --verify-objects' '
git rev-list --verify-objects --all >/dev/null 2>out &&
test_cmp empty out
'
test_expect_success 'rev-list --verify-objects with bad sha1' '
sha=$(echo blob | git hash-object -w --stdin) &&
old=$(echo $sha | sed "s+^..+&/+") &&
new=$(dirname $old)/ffffffffffffffffffffffffffffffffffffff &&
sha="$(dirname $new)$(basename $new)" &&
mv .git/objects/$old .git/objects/$new &&
test_when_finished "remove_object $sha" &&
git update-index --add --cacheinfo 100644 $sha foo &&
test_when_finished "git read-tree -u --reset HEAD" &&
tree=$(git write-tree) &&
test_when_finished "remove_object $tree" &&
cmt=$(echo bogus | git commit-tree $tree) &&
test_when_finished "remove_object $cmt" &&
git update-ref refs/heads/bogus $cmt &&
test_when_finished "git update-ref -d refs/heads/bogus" &&
test_might_fail git rev-list --verify-objects refs/heads/bogus >/dev/null 2>out &&
cat out &&
grep -q "error: sha1 mismatch 63ffffffffffffffffffffffffffffffffffffff" out
'
fsck: support demoting errors to warnings We already have support in `git receive-pack` to deal with some legacy repositories which have non-fatal issues. Let's make `git fsck` itself useful with such repositories, too, by allowing users to ignore known issues, or at least demote those issues to mere warnings. Example: `git -c fsck.missingEmail=ignore fsck` would hide problems with missing emails in author, committer and tagger lines. In the same spirit that `git receive-pack`'s usage of the fsck machinery differs from `git fsck`'s – some of the non-fatal warnings in `git fsck` are fatal with `git receive-pack` when receive.fsckObjects = true, for example – we strictly separate the fsck.<msg-id> from the receive.fsck.<msg-id> settings. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-22 23:27:06 +08:00
test_expect_success 'force fsck to ignore double author' '
git cat-file commit HEAD >basis &&
sed "s/^author .*/&,&/" <basis | tr , \\n >multiple-authors &&
new=$(git hash-object -t commit -w --stdin <multiple-authors) &&
test_when_finished "remove_object $new" &&
git update-ref refs/heads/bogus "$new" &&
test_when_finished "git update-ref -d refs/heads/bogus" &&
test_must_fail git fsck &&
git -c fsck.multipleAuthors=ignore fsck
'
fsck: detect null sha1 in tree entries Short of somebody happening to beat the 1 in 2^160 odds of actually generating content that hashes to the null sha1, we should never see this value in a tree entry. So let's have fsck warn if it it seen. As in the previous commit, we test both blob and submodule entries to future-proof the test suite against the implementation depending on connectivity to notice the error. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-28 23:06:29 +08:00
_bz='\0'
_bz5="$_bz$_bz$_bz$_bz$_bz"
_bz20="$_bz5$_bz5$_bz5$_bz5"
test_expect_success 'fsck notices blob entry pointing to null sha1' '
(git init null-blob &&
cd null-blob &&
sha=$(printf "100644 file$_bz$_bz20" |
git hash-object -w --stdin -t tree) &&
git fsck 2>out &&
cat out &&
grep "warning.*null sha1" out
)
'
test_expect_success 'fsck notices submodule entry pointing to null sha1' '
(git init null-commit &&
cd null-commit &&
sha=$(printf "160000 submodule$_bz$_bz20" |
git hash-object -w --stdin -t tree) &&
git fsck 2>out &&
cat out &&
grep "warning.*null sha1" out
)
'
fsck: complain about HFS+ ".git" aliases in trees Now that the index can block pathnames that case-fold to ".git" on HFS+, it would be helpful for fsck to notice such problematic paths. This lets servers which use receive.fsckObjects block them before the damage spreads. Note that the fsck check is always on, even for systems without core.protectHFS set. This is technically more restrictive than we need to be, as a set of users on ext4 could happily use these odd filenames without caring about HFS+. However, on balance, it's helpful for all servers to block these (because the paths can be used for mischief, and servers which bother to fsck would want to stop the spread whether they are on HFS+ themselves or not), and hardly anybody will be affected (because the blocked names are variants of .git with invisible Unicode code-points mixed in, meaning mischief is almost certainly what the tree author had in mind). Ideally these would be controlled by a separate "fsck.protectHFS" flag. However, it would be much nicer to be able to enable/disable _any_ fsck flag individually, and any scheme we choose should match such a system. Given the likelihood of anybody using such a path in practice, it is not unreasonable to wait until such a system materializes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-16 07:21:57 +08:00
while read name path pretty; do
t1450: refactor ".", "..", and ".git" fsck tests We check that fsck notices and complains about confusing paths in trees. However, there are a few shortcomings: 1. We check only for these paths as file entries, not as intermediate paths (so ".git" and not ".git/foo"). 2. We check "." and ".." together, so it is possible that we notice only one and not the other. 3. We repeat a lot of boilerplate. Let's use some loops to be more thorough in our testing, and still end up with shorter code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 02:40:11 +08:00
while read mode type; do
fsck: complain about HFS+ ".git" aliases in trees Now that the index can block pathnames that case-fold to ".git" on HFS+, it would be helpful for fsck to notice such problematic paths. This lets servers which use receive.fsckObjects block them before the damage spreads. Note that the fsck check is always on, even for systems without core.protectHFS set. This is technically more restrictive than we need to be, as a set of users on ext4 could happily use these odd filenames without caring about HFS+. However, on balance, it's helpful for all servers to block these (because the paths can be used for mischief, and servers which bother to fsck would want to stop the spread whether they are on HFS+ themselves or not), and hardly anybody will be affected (because the blocked names are variants of .git with invisible Unicode code-points mixed in, meaning mischief is almost certainly what the tree author had in mind). Ideally these would be controlled by a separate "fsck.protectHFS" flag. However, it would be much nicer to be able to enable/disable _any_ fsck flag individually, and any scheme we choose should match such a system. Given the likelihood of anybody using such a path in practice, it is not unreasonable to wait until such a system materializes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-16 07:21:57 +08:00
: ${pretty:=$path}
test_expect_success "fsck notices $pretty as $type" '
t1450: refactor ".", "..", and ".git" fsck tests We check that fsck notices and complains about confusing paths in trees. However, there are a few shortcomings: 1. We check only for these paths as file entries, not as intermediate paths (so ".git" and not ".git/foo"). 2. We check "." and ".." together, so it is possible that we notice only one and not the other. 3. We repeat a lot of boilerplate. Let's use some loops to be more thorough in our testing, and still end up with shorter code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 02:40:11 +08:00
(
git init $name-$type &&
cd $name-$type &&
echo content >file &&
git add file &&
git commit -m base &&
blob=$(git rev-parse :file) &&
tree=$(git rev-parse HEAD^{tree}) &&
value=$(eval "echo \$$type") &&
printf "$mode $type %s\t%s" "$value" "$path" >bad &&
fsck: complain about NTFS ".git" aliases in trees Now that the index can block pathnames that can be mistaken to mean ".git" on NTFS and FAT32, it would be helpful for fsck to notice such problematic paths. This lets servers which use receive.fsckObjects block them before the damage spreads. Note that the fsck check is always on, even for systems without core.protectNTFS set. This is technically more restrictive than we need to be, as a set of users on ext4 could happily use these odd filenames without caring about NTFS. However, on balance, it's helpful for all servers to block these (because the paths can be used for mischief, and servers which bother to fsck would want to stop the spread whether they are on NTFS themselves or not), and hardly anybody will be affected (because the blocked names are variants of .git or git~1, meaning mischief is almost certainly what the tree author had in mind). Ideally these would be controlled by a separate "fsck.protectNTFS" flag. However, it would be much nicer to be able to enable/disable _any_ fsck flag individually, and any scheme we choose should match such a system. Given the likelihood of anybody using such a path in practice, it is not unreasonable to wait until such a system materializes. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-11 05:28:27 +08:00
bad_tree=$(git mktree <bad) &&
t1450: refactor ".", "..", and ".git" fsck tests We check that fsck notices and complains about confusing paths in trees. However, there are a few shortcomings: 1. We check only for these paths as file entries, not as intermediate paths (so ".git" and not ".git/foo"). 2. We check "." and ".." together, so it is possible that we notice only one and not the other. 3. We repeat a lot of boilerplate. Let's use some loops to be more thorough in our testing, and still end up with shorter code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 02:40:11 +08:00
git fsck 2>out &&
cat out &&
fsck: complain about NTFS ".git" aliases in trees Now that the index can block pathnames that can be mistaken to mean ".git" on NTFS and FAT32, it would be helpful for fsck to notice such problematic paths. This lets servers which use receive.fsckObjects block them before the damage spreads. Note that the fsck check is always on, even for systems without core.protectNTFS set. This is technically more restrictive than we need to be, as a set of users on ext4 could happily use these odd filenames without caring about NTFS. However, on balance, it's helpful for all servers to block these (because the paths can be used for mischief, and servers which bother to fsck would want to stop the spread whether they are on NTFS themselves or not), and hardly anybody will be affected (because the blocked names are variants of .git or git~1, meaning mischief is almost certainly what the tree author had in mind). Ideally these would be controlled by a separate "fsck.protectNTFS" flag. However, it would be much nicer to be able to enable/disable _any_ fsck flag individually, and any scheme we choose should match such a system. Given the likelihood of anybody using such a path in practice, it is not unreasonable to wait until such a system materializes. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-11 05:28:27 +08:00
grep "warning.*tree $bad_tree" out
t1450: refactor ".", "..", and ".git" fsck tests We check that fsck notices and complains about confusing paths in trees. However, there are a few shortcomings: 1. We check only for these paths as file entries, not as intermediate paths (so ".git" and not ".git/foo"). 2. We check "." and ".." together, so it is possible that we notice only one and not the other. 3. We repeat a lot of boilerplate. Let's use some loops to be more thorough in our testing, and still end up with shorter code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 02:40:11 +08:00
)'
done <<-\EOF
100644 blob
040000 tree
EOF
fsck: complain about HFS+ ".git" aliases in trees Now that the index can block pathnames that case-fold to ".git" on HFS+, it would be helpful for fsck to notice such problematic paths. This lets servers which use receive.fsckObjects block them before the damage spreads. Note that the fsck check is always on, even for systems without core.protectHFS set. This is technically more restrictive than we need to be, as a set of users on ext4 could happily use these odd filenames without caring about HFS+. However, on balance, it's helpful for all servers to block these (because the paths can be used for mischief, and servers which bother to fsck would want to stop the spread whether they are on HFS+ themselves or not), and hardly anybody will be affected (because the blocked names are variants of .git with invisible Unicode code-points mixed in, meaning mischief is almost certainly what the tree author had in mind). Ideally these would be controlled by a separate "fsck.protectHFS" flag. However, it would be much nicer to be able to enable/disable _any_ fsck flag individually, and any scheme we choose should match such a system. Given the likelihood of anybody using such a path in practice, it is not unreasonable to wait until such a system materializes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-16 07:21:57 +08:00
done <<-EOF
t1450: refactor ".", "..", and ".git" fsck tests We check that fsck notices and complains about confusing paths in trees. However, there are a few shortcomings: 1. We check only for these paths as file entries, not as intermediate paths (so ".git" and not ".git/foo"). 2. We check "." and ".." together, so it is possible that we notice only one and not the other. 3. We repeat a lot of boilerplate. Let's use some loops to be more thorough in our testing, and still end up with shorter code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 02:40:11 +08:00
dot .
dotdot ..
dotgit .git
fsck: notice .git case-insensitively We complain about ".git" in a tree because it cannot be loaded into the index or checked out. Since we now also reject ".GIT" case-insensitively, fsck should notice the same, so that errors do not propagate. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 02:40:44 +08:00
dotgit-case .GIT
fsck: complain about HFS+ ".git" aliases in trees Now that the index can block pathnames that case-fold to ".git" on HFS+, it would be helpful for fsck to notice such problematic paths. This lets servers which use receive.fsckObjects block them before the damage spreads. Note that the fsck check is always on, even for systems without core.protectHFS set. This is technically more restrictive than we need to be, as a set of users on ext4 could happily use these odd filenames without caring about HFS+. However, on balance, it's helpful for all servers to block these (because the paths can be used for mischief, and servers which bother to fsck would want to stop the spread whether they are on HFS+ themselves or not), and hardly anybody will be affected (because the blocked names are variants of .git with invisible Unicode code-points mixed in, meaning mischief is almost certainly what the tree author had in mind). Ideally these would be controlled by a separate "fsck.protectHFS" flag. However, it would be much nicer to be able to enable/disable _any_ fsck flag individually, and any scheme we choose should match such a system. Given the likelihood of anybody using such a path in practice, it is not unreasonable to wait until such a system materializes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-16 07:21:57 +08:00
dotgit-unicode .gI${u200c}T .gI{u200c}T
fsck: complain about NTFS ".git" aliases in trees Now that the index can block pathnames that can be mistaken to mean ".git" on NTFS and FAT32, it would be helpful for fsck to notice such problematic paths. This lets servers which use receive.fsckObjects block them before the damage spreads. Note that the fsck check is always on, even for systems without core.protectNTFS set. This is technically more restrictive than we need to be, as a set of users on ext4 could happily use these odd filenames without caring about NTFS. However, on balance, it's helpful for all servers to block these (because the paths can be used for mischief, and servers which bother to fsck would want to stop the spread whether they are on NTFS themselves or not), and hardly anybody will be affected (because the blocked names are variants of .git or git~1, meaning mischief is almost certainly what the tree author had in mind). Ideally these would be controlled by a separate "fsck.protectNTFS" flag. However, it would be much nicer to be able to enable/disable _any_ fsck flag individually, and any scheme we choose should match such a system. Given the likelihood of anybody using such a path in practice, it is not unreasonable to wait until such a system materializes. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-11 05:28:27 +08:00
dotgit-case2 .Git
git-tilde1 git~1
dotgitdot .git.
dot-backslash-case .\\\\.GIT\\\\foobar
dotgit-case-backslash .git\\\\foobar
t1450: refactor ".", "..", and ".git" fsck tests We check that fsck notices and complains about confusing paths in trees. However, there are a few shortcomings: 1. We check only for these paths as file entries, not as intermediate paths (so ".git" and not ".git/foo"). 2. We check "." and ".." together, so it is possible that we notice only one and not the other. 3. We repeat a lot of boilerplate. Let's use some loops to be more thorough in our testing, and still end up with shorter code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 02:40:11 +08:00
EOF
fsck: warn about ".git" in trees Having a ".git" entry inside a tree can cause confusing results on checkout. At the top-level, you could not checkout such a tree, as it would complain about overwriting the real ".git" directory. In a subdirectory, you might check it out, but performing operations in the subdirectory would confusingly consider the in-tree ".git" directory as the repository. The regular git tools already make it hard to accidentally add such an entry to a tree, and do not allow such entries to enter the index at all. Teaching fsck about it provides an additional safety check, and let's us avoid propagating any such bogosity when transfer.fsckObjects is on. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-29 05:35:29 +08:00
is_hfs_dotgit: loosen over-eager match of \u{..47} Our is_hfs_dotgit function relies on the hackily-implemented next_hfs_char to give us the next character that an HFS+ filename comparison would look at. It's hacky because it doesn't implement the full case-folding table of HFS+; it gives us just enough to see if the path matches ".git". At the end of next_hfs_char, we use tolower() to convert our 32-bit code point to lowercase. Our tolower() implementation only takes an 8-bit char, though; it throws away the upper 24 bits. This means we can't have any false negatives for is_hfs_dotgit. We only care about matching 7-bit ASCII characters in ".git", and we will correctly process 'G' or 'g'. However, we _can_ have false positives. Because we throw away the upper bits, code point \u{0147} (for example) will look like 'G' and get downcased to 'g'. It's not known whether a sequence of code points whose truncation ends up as ".git" is meaningful in any language, but it does not hurt to be more accurate here. We can just pass out the full 32-bit code point, and compare it manually to the upper and lowercase characters we care about. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-23 16:45:36 +08:00
test_expect_success 'fsck allows .Ňit' '
(
git init not-dotgit &&
cd not-dotgit &&
echo content >file &&
git add file &&
git commit -m base &&
blob=$(git rev-parse :file) &&
printf "100644 blob $blob\t.\\305\\207it" >tree &&
tree=$(git mktree <tree) &&
git fsck 2>err &&
test_line_count = 0 err
)
'
fsck: return non-zero status on missing ref tips Fsck tries hard to detect missing objects, and will complain (and exit non-zero) about any inter-object links that are missing. However, it will not exit non-zero for any missing ref tips, meaning that a severely broken repository may still pass "git fsck && echo ok". The problem is that we use for_each_ref to iterate over the ref tips, which hides broken tips. It does at least print an error from the refs.c code, but fsck does not ever see the ref and cannot note the problem in its exit code. We can solve this by using for_each_rawref and noting the error ourselves. In addition to adding tests for this case, we add tests for all types of missing-object links (all of which worked, but which we were not testing). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-09-12 11:38:30 +08:00
# create a static test repo which is broken by omitting
# one particular object ($1, which is looked up via rev-parse
# in the new repository).
create_repo_missing () {
rm -rf missing &&
git init missing &&
(
cd missing &&
git commit -m one --allow-empty &&
mkdir subdir &&
echo content >subdir/file &&
git add subdir/file &&
git commit -m two &&
unrelated=$(echo unrelated | git hash-object --stdin -w) &&
git tag -m foo tag $unrelated &&
sha1=$(git rev-parse --verify "$1") &&
path=$(echo $sha1 | sed 's|..|&/|') &&
rm .git/objects/$path
)
}
test_expect_success 'fsck notices missing blob' '
create_repo_missing HEAD:subdir/file &&
test_must_fail git -C missing fsck
'
test_expect_success 'fsck notices missing subtree' '
create_repo_missing HEAD:subdir &&
test_must_fail git -C missing fsck
'
test_expect_success 'fsck notices missing root tree' '
create_repo_missing HEAD^{tree} &&
test_must_fail git -C missing fsck
'
test_expect_success 'fsck notices missing parent' '
create_repo_missing HEAD^ &&
test_must_fail git -C missing fsck
'
test_expect_success 'fsck notices missing tagged object' '
create_repo_missing tag^{blob} &&
test_must_fail git -C missing fsck
'
test_expect_success 'fsck notices ref pointing to missing commit' '
create_repo_missing HEAD &&
test_must_fail git -C missing fsck
'
test_expect_success 'fsck notices ref pointing to missing tag' '
create_repo_missing tag &&
test_must_fail git -C missing fsck
'
fsck: introduce `git fsck --connectivity-only` This option avoids unpacking each and all blob objects, and just verifies the connectivity. In particular with large repositories, this speeds up the operation, at the expense of missing corrupt blobs, ignoring unreachable objects and other fsck issues, if any. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-22 23:27:12 +08:00
test_expect_success 'fsck --connectivity-only' '
rm -rf connectivity-only &&
git init connectivity-only &&
(
cd connectivity-only &&
touch empty &&
git add empty &&
test_commit empty &&
empty=.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 &&
rm -f $empty &&
echo invalid >$empty &&
test_must_fail git fsck --strict &&
git fsck --strict --connectivity-only &&
tree=$(git rev-parse HEAD:) &&
suffix=${tree#??} &&
tree=.git/objects/${tree%$suffix}/$suffix &&
rm -f $tree &&
echo invalid >$tree &&
test_must_fail git fsck --strict --connectivity-only
)
'
fsck: HEAD is part of refs By default we looked at all refs but not HEAD. The only thing that made fsck not lose sight of commits that are only reachable from a detached HEAD was the reflog for the HEAD. This fixes it, with a new test. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-30 16:33:00 +08:00
test_done
Reference in New Issue Copy Permalink