undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
df805ed6cf
git-commit-vandalism/t/t1450-fsck.sh

815 lines
24 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 09:33:00 +01: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 03:47:07 +02: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 09:33:00 +01: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 03:47:07 +02: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-26 23:50:34 +02: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 09:33:00 +01: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-26 23:50:34 +02: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 09:33:00 +01:00
git checkout HEAD^0 &&
test_commit B fileB two &&
git tag -d A B &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 23:57:25 +02:00
git reflog expire --expire=now --all
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 09:33:00 +01: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 09:50:54 +01: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-28 23:55:39 +01: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 03:47:07 +02:00
) &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 23:57:25 +02:00
test_must_be_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 09:50:54 +01: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 03:47:07 +02:00
test_expect_success 'HEAD is part of refs, valid objects appear valid' '
git fsck >actual 2>&1 &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 23:57:25 +02:00
test_must_be_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-26 23:50:34 +02: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 12:13:39 +01: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 03:47:07 +02:00
test_expect_success 'setup: helpers for corruption tests' '
sha1_file() {
t1450: refactor loose-object removal Commit 90cf590f5 (fsck: optionally show more helpful info for broken links, 2016-07-17) added a remove_loose_object() helper, but we already had a remove_object() helper that did the same thing. Let's combine these into one. The implementations had a few subtle differences, so I've tried to take the best of both: - the original used "sed", but the newer version avoids spawning an extra process - the original processed "$*", which was nonsense, as it assumed only a single sha1. Use "$1" to make that more clear. - the newer version ran an extra rev-parse, but it was not necessary; it's sole caller already converted the argument into a raw sha1 - the original used "rm -f", whereas the new one uses "rm". The latter is better because it may notice a bug or other unexpected failure in the test. (The original does check that the object exists before we remove it, which is good, but that's a subset of the possible unexpected conditions). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 18:54:10 +01:00
remainder=${1#??} &&
firsttwo=${1%$remainder} &&
echo ".git/objects/$firsttwo/$remainder"
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 03:47:07 +02:00
} &&
remove_object() {
t1450: refactor loose-object removal Commit 90cf590f5 (fsck: optionally show more helpful info for broken links, 2016-07-17) added a remove_loose_object() helper, but we already had a remove_object() helper that did the same thing. Let's combine these into one. The implementations had a few subtle differences, so I've tried to take the best of both: - the original used "sed", but the newer version avoids spawning an extra process - the original processed "$*", which was nonsense, as it assumed only a single sha1. Use "$1" to make that more clear. - the newer version ran an extra rev-parse, but it was not necessary; it's sole caller already converted the argument into a raw sha1 - the original used "rm -f", whereas the new one uses "rm". The latter is better because it may notice a bug or other unexpected failure in the test. (The original does check that the object exists before we remove it, which is good, but that's a subset of the possible unexpected conditions). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 18:54:10 +01:00
rm "$(sha1_file "$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 03:47:07 +02: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 12:13:39 +01: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 02:46:54 +01: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 12:13:39 +01: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 03:47:07 +02: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 12:13:39 +01: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 03:47:07 +02: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 12:13:39 +01: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 03:47:07 +02: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 12:13:39 +01: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 03:47:07 +02: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 12:13:39 +01: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 03:47:07 +02: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-29 22:31:46 +02: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 03:47:07 +02: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 12:13:39 +01: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 03:47:07 +02:00
git rev-parse HEAD^{tree} >.git/refs/heads/invalid &&
test_when_finished "git update-ref -d refs/heads/invalid" &&
fsck: exit with non-zero when problems are found After finding some problems (e.g. a ref refs/heads/X points at an object that is not a commit) and issuing an error message, the program failed to signal the fact that it found an error by a non-zero exit status. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-23 22:46:39 +02: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 03:47:07 +02: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 12:13:39 +01:00
'
fsck: exit with non-zero when problems are found After finding some problems (e.g. a ref refs/heads/X points at an object that is not a commit) and issuing an error message, the program failed to signal the fact that it found an error by a non-zero exit status. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-23 22:46:39 +02:00
test_expect_success 'HEAD link pointing at a funny object' '
test_when_finished "mv .git/SAVED_HEAD .git/HEAD" &&
mv .git/HEAD .git/SAVED_HEAD &&
echo 0000000000000000000000000000000000000000 >.git/HEAD &&
# avoid corrupt/broken HEAD from interfering with repo discovery
test_must_fail env GIT_DIR=.git git fsck 2>out &&
cat out &&
grep "detached HEAD points" out
'
test_expect_success 'HEAD link pointing at a funny place' '
test_when_finished "mv .git/SAVED_HEAD .git/HEAD" &&
mv .git/HEAD .git/SAVED_HEAD &&
echo "ref: refs/funny/place" >.git/HEAD &&
# avoid corrupt/broken HEAD from interfering with repo discovery
test_must_fail env GIT_DIR=.git git fsck 2>out &&
cat out &&
grep "HEAD points to something strange" out
'
fsck: check HEAD and reflog from other worktrees fsck is a repo-wide operation and should check all references no matter which worktree they are associated to. Reported-by: Jeff King <peff@peff.net> Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-21 10:08:58 +02:00
test_expect_success 'HEAD link pointing at a funny object (from different wt)' '
test_when_finished "mv .git/SAVED_HEAD .git/HEAD" &&
test_when_finished "rm -rf .git/worktrees wt" &&
git worktree add wt &&
mv .git/HEAD .git/SAVED_HEAD &&
echo $ZERO_OID >.git/HEAD &&
# avoid corrupt/broken HEAD from interfering with repo discovery
test_must_fail git -C wt fsck 2>out &&
grep "main-worktree/HEAD: detached HEAD points" out
'
test_expect_success 'other worktree HEAD link pointing at a funny object' '
test_when_finished "rm -rf .git/worktrees other" &&
git worktree add other &&
echo $ZERO_OID >.git/worktrees/other/HEAD &&
test_must_fail git fsck 2>out &&
grep "worktrees/other/HEAD: detached HEAD points" out
'
test_expect_success 'other worktree HEAD link pointing at missing object' '
test_when_finished "rm -rf .git/worktrees other" &&
git worktree add other &&
echo "Contents missing from repo" | git hash-object --stdin >.git/worktrees/other/HEAD &&
test_must_fail git fsck 2>out &&
grep "worktrees/other/HEAD: invalid sha1 pointer" out
'
test_expect_success 'other worktree HEAD link pointing at a funny place' '
test_when_finished "rm -rf .git/worktrees other" &&
git worktree add other &&
echo "ref: refs/funny/place" >.git/worktrees/other/HEAD &&
test_must_fail git fsck 2>out &&
grep "worktrees/other/HEAD points to something strange" 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-24 18:06:08 +02: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 03:47:07 +02: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-24 18:06:08 +02: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 03:47:07 +02: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-24 18:06:08 +02: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 03:47:07 +02: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-24 18:06:08 +02: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 03:47:07 +02: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-24 18:06:08 +02: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 03:47:07 +02: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-29 22:31:46 +02: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-24 18:06:08 +02: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 12:13:39 +01: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 12:21:10 +02: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 12:21:09 +02: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-29 22:31:46 +02: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 12:21:09 +02: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 12:21:10 +02: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 12:21:09 +02: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-29 22:31:46 +02: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 12:21:09 +02: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 12:21:10 +02: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 12:21:09 +02: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-29 22:31:46 +02: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 12:21:09 +02: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 08:39:04 +01: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-29 22:31:46 +02: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 08:39:04 +01:00
cat out &&
grep "error in commit $new.*integer overflow" out
'
t1450: add tests for NUL in headers of commits and tags Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Jeff King <peff@peff.net>
2015-11-19 17:20:14 +01:00
test_expect_success 'commit with NUL in header' '
git cat-file commit HEAD >basis &&
sed "s/author ./author Q/" <basis | q_to_nul >commit-NUL-header &&
new=$(git hash-object -t commit -w --stdin <commit-NUL-header) &&
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 2>out &&
cat out &&
grep "error in commit $new.*unterminated header: NUL at offset" out
'
fsck: handle bad trees like other errors Instead of dying when fsck hits a malformed tree object, log the error like any other and continue. Now fsck can tell the user which tree is bad, too. Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-27 22:59:51 +02:00
test_expect_success 'tree object with duplicate entries' '
t1450: clean up sub-objects in duplicate-entry test This test creates a multi-level set of trees, but its cleanup routine only removes the top-level tree. After the test finishes, the inner tree and the blob it points to remain, making the inner tree dangling. A later test ("cleaned up") verifies that we've removed any cruft and "git fsck" output is clean. This passes only because of a bug in git-fsck which fails to notice dangling trees. In preparation for fixing the bug, let's teach this earlier test to clean up after itself correctly. We have to remove the inner tree (and therefore the blob, too, which becomes dangling after removing that tree). Since the setup code happens inside a subshell, we can't just set a variable for each object. However, we can stuff all of the sha1s into the $T output variable, which is not used for anything except cleanup. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-16 22:24:03 +01:00
test_when_finished "for i in \$T; do remove_object \$i; done" &&
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-29 22:31:46 +02:00
T=$(
GIT_INDEX_FILE=test-index &&
export GIT_INDEX_FILE &&
rm -f test-index &&
>x &&
git add x &&
t1450: clean up sub-objects in duplicate-entry test This test creates a multi-level set of trees, but its cleanup routine only removes the top-level tree. After the test finishes, the inner tree and the blob it points to remain, making the inner tree dangling. A later test ("cleaned up") verifies that we've removed any cruft and "git fsck" output is clean. This passes only because of a bug in git-fsck which fails to notice dangling trees. In preparation for fixing the bug, let's teach this earlier test to clean up after itself correctly. We have to remove the inner tree (and therefore the blob, too, which becomes dangling after removing that tree). Since the setup code happens inside a subshell, we can't just set a variable for each object. However, we can stuff all of the sha1s into the $T output variable, which is not used for anything except cleanup. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-16 22:24:03 +01:00
git rev-parse :x &&
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-29 22:31:46 +02:00
T=$(git write-tree) &&
t1450: clean up sub-objects in duplicate-entry test This test creates a multi-level set of trees, but its cleanup routine only removes the top-level tree. After the test finishes, the inner tree and the blob it points to remain, making the inner tree dangling. A later test ("cleaned up") verifies that we've removed any cruft and "git fsck" output is clean. This passes only because of a bug in git-fsck which fails to notice dangling trees. In preparation for fixing the bug, let's teach this earlier test to clean up after itself correctly. We have to remove the inner tree (and therefore the blob, too, which becomes dangling after removing that tree). Since the setup code happens inside a subshell, we can't just set a variable for each object. However, we can stuff all of the sha1s into the $T output variable, which is not used for anything except cleanup. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-16 22:24:03 +01:00
echo $T &&
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-29 22:31:46 +02:00
(
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
'
fsck: handle bad trees like other errors Instead of dying when fsck hits a malformed tree object, log the error like any other and continue. Now fsck can tell the user which tree is bad, too. Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-27 22:59:51 +02:00
test_expect_success 'unparseable tree object' '
test_when_finished "git update-ref -d refs/heads/wrong" &&
test_when_finished "remove_object \$tree_sha1" &&
test_when_finished "remove_object \$commit_sha1" &&
tree_sha1=$(printf "100644 \0twenty-bytes-of-junk" | git hash-object -t tree --stdin -w --literally) &&
commit_sha1=$(git commit-tree $tree_sha1) &&
git update-ref refs/heads/wrong $commit_sha1 &&
test_must_fail git fsck 2>out &&
test_i18ngrep "error: empty filename in tree entry" out &&
test_i18ngrep "$tree_sha1" out &&
test_i18ngrep ! "fatal: empty filename in tree entry" out
'
fsck: handle NULL return of lookup_blob() and lookup_tree() lookup_blob() and lookup_tree() can return NULL if they find an object of an unexpected type. Accessing the object member is undefined in that case. Cast the result to a struct object pointer instead; we can do that because object is the first member of all object types. This trick is already used in other places in the code. An error message is already shown by object_as_type(), which is called by the lookup functions. The walk callback functions are expected to handle NULL object pointers passed to them, but put_object_name() needs a valid object, so avoid calling it without one. Suggested-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-05 21:41:26 +02:00
hex2oct() {
perl -ne 'printf "\\%03o", hex for /../g'
}
test_expect_success 'tree entry with type mismatch' '
test_when_finished "remove_object \$blob" &&
test_when_finished "remove_object \$tree" &&
test_when_finished "remove_object \$commit" &&
test_when_finished "git update-ref -d refs/heads/type_mismatch" &&
blob=$(echo blob | git hash-object -w --stdin) &&
blob_bin=$(echo $blob | hex2oct) &&
tree=$(
printf "40000 dir\0${blob_bin}100644 file\0${blob_bin}" |
git hash-object -t tree --stdin -w --literally
) &&
commit=$(git commit-tree $tree) &&
git update-ref refs/heads/type_mismatch $commit &&
test_must_fail git fsck >out 2>&1 &&
test_i18ngrep "is a blob, not a tree" out &&
test_i18ngrep ! "dangling blob" 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 01:18:44 +01: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 02:46:54 +01: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 03:47:07 +02: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 01:18:44 +01: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 12:13:39 +01: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 03:47:07 +02: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 12:13:39 +01: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 01:18:44 +01: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 03:47:07 +02: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 00:08:16 +02: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 12:13:39 +01: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 16:26:41 +02: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 06:48:13 +01: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 17:25:52 +02: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 06:48:13 +01: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 16:26:41 +02: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-11 23:16:36 +02: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
'
fsck: treat a NUL in a tag header as an error We check the return value of verify_header() for commits already, so do the same for tags as well. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Jeff King <peff@peff.net>
2015-11-19 17:25:31 +01:00
test_expect_success 'tag with NUL in header' '
t1450: add tests for NUL in headers of commits and tags Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Jeff King <peff@peff.net>
2015-11-19 17:20:14 +01:00
sha=$(git rev-parse HEAD) &&
q_to_nul >tag-NUL-header <<-EOF &&
object $sha
type commit
tag contains-Q-in-header
tagger T A Gger <tagger@example.com> 1234567890 -0000
This is an invalid tag.
EOF
tag=$(git hash-object --literally -t tag -w --stdin <tag-NUL-header) &&
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 &&
cat out &&
grep "error in tag $tag.*unterminated header: NUL at offset" 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 03:47:07 +02:00
test_expect_success 'cleaned up' '
git fsck >actual 2>&1 &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 23:57:25 +02:00
test_must_be_empty actual
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 03:47:07 +02: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 12:13:39 +01: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-13 21:17:11 +01:00
test_expect_success 'rev-list --verify-objects' '
git rev-list --verify-objects --all >/dev/null 2>out &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 23:57:25 +02:00
test_must_be_empty out
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-13 21:17:11 +01:00
'
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 &&
object.c: mark more strings for translation Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-21 09:49:33 +02:00
test_i18ngrep -q "error: sha1 mismatch 63ffffffffffffffffffffffffffffffffffffff" out
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-13 21:17:11 +01:00
'
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 17:27:06 +02: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 17:06:29 +02: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 00:21:57 +01: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-24 19:40:11 +01: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 00:21:57 +01: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-24 19:40:11 +01: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-10 22:28:27 +01: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-24 19:40:11 +01: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-10 22:28:27 +01: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-24 19:40:11 +01: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 00:21:57 +01: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-24 19:40:11 +01: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-24 19:40:44 +01: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 00:21:57 +01: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-10 22:28:27 +01: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-24 19:40:11 +01: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-28 22:35:29 +01: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 09:45:36 +01: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: detect and warn a commit with embedded NUL Even though a Git commit object is designed to be capable of storing any binary data as its payload, in practice people use it to describe the changes in textual form, and tools like "git log" are designed to treat the payload as text. Detect and warn when we see any commit object with a NUL byte in it. Note that a NUL byte in the header part is already detected as a grave error. This change is purely about the message part. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-14 19:58:22 +02:00
test_expect_success 'NUL in commit' '
rm -fr nul-in-commit &&
git init nul-in-commit &&
(
cd nul-in-commit &&
git commit --allow-empty -m "initial commitQNUL after message" &&
git cat-file commit HEAD >original &&
q_to_nul <original >munged &&
git hash-object -w -t commit --stdin <munged >name &&
git branch bad $(cat name) &&
test_must_fail git -c fsck.nulInCommit=error fsck 2>warn.1 &&
grep nulInCommit warn.1 &&
git fsck 2>warn.2 &&
grep nulInCommit warn.2
)
'
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 05:38:30 +02: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 17:27:12 +02: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 &&
fsck: prepare dummy objects for --connectivity-check Normally fsck makes a pass over all objects to check their integrity, and then follows up with a reachability check to make sure we have all of the referenced objects (and to know which ones are dangling). The latter checks for the HAS_OBJ flag in obj->flags to see if we found the object in the first pass. Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`, 2015-06-22) taught fsck to skip the initial pass, and to fallback to has_sha1_file() instead of the HAS_OBJ check. However, it converted only one HAS_OBJ check to use has_sha1_file(). But there are many other places in builtin/fsck.c that assume that the flag is set (or that lookup_object() will return an object at all). This leads to several bugs with --connectivity-only: 1. mark_object() will not queue objects for examination, so recursively following links from commits to trees, etc, did nothing. I.e., we were checking the reachability of hardly anything at all. 2. When a set of heads is given on the command-line, we use lookup_object() to see if they exist. But without the initial pass, we assume nothing exists. 3. When loading reflog entries, we do a similar lookup_object() check, and complain that the reflog is broken if the object doesn't exist in our hash. So in short, --connectivity-only is broken pretty badly, and will claim that your repository is fine when it's not. Presumably nobody noticed for a few reasons. One is that the embedded test does not actually test the recursive nature of the reachability check. All of the missing objects are still in the index, and we directly check items from the index. This patch modifies the test to delete the index, which shows off breakage (1). Another is that --connectivity-only just skips the initial pass for loose objects. So on a real repository, the packed objects were still checked correctly. But on the flipside, it means that "git fsck --connectivity-only" still checks the sha1 of all of the packed objects, nullifying its original purpose of being a faster git-fsck. And of course the final problem is that the bug only shows up when there _is_ corruption, which is rare. So anybody running "git fsck --connectivity-only" proactively would assume it was being thorough, when it was not. One possibility for fixing this is to find all of the spots that rely on HAS_OBJ and tweak them for the connectivity-only case. But besides the risk that we might miss a spot (and I found three already, corresponding to the three bugs above), there are other parts of fsck that _can't_ work without a full list of objects. E.g., the list of dangling objects. Instead, let's make the connectivity-only case look more like the normal case. Rather than skip the initial pass completely, we'll do an abbreviated one that sets up the HAS_OBJ flag for each object, without actually loading the object data. That's simple and fast, and we don't have to care about the connectivity_only flag in the rest of the code at all. While we're at it, let's make sure we treat loose and packed objects the same (i.e., setting up dummy objects for both and skipping the actual sha1 check). That makes the connectivity-only check actually fast on a real repo (40 seconds versus 180 seconds on my copy of linux.git). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 22:32:57 +01:00
# Drop the index now; we want to be sure that we
# recursively notice the broken objects
# because they are reachable from refs, not because
# they are in the index.
rm -f .git/index &&
# corrupt the blob, but in a way that we can still identify
# its type. That lets us see that --connectivity-only is
# not actually looking at the contents, but leaves it
# free to examine the type if it chooses.
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 17:27:12 +02:00
empty=.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 &&
fsck: prepare dummy objects for --connectivity-check Normally fsck makes a pass over all objects to check their integrity, and then follows up with a reachability check to make sure we have all of the referenced objects (and to know which ones are dangling). The latter checks for the HAS_OBJ flag in obj->flags to see if we found the object in the first pass. Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`, 2015-06-22) taught fsck to skip the initial pass, and to fallback to has_sha1_file() instead of the HAS_OBJ check. However, it converted only one HAS_OBJ check to use has_sha1_file(). But there are many other places in builtin/fsck.c that assume that the flag is set (or that lookup_object() will return an object at all). This leads to several bugs with --connectivity-only: 1. mark_object() will not queue objects for examination, so recursively following links from commits to trees, etc, did nothing. I.e., we were checking the reachability of hardly anything at all. 2. When a set of heads is given on the command-line, we use lookup_object() to see if they exist. But without the initial pass, we assume nothing exists. 3. When loading reflog entries, we do a similar lookup_object() check, and complain that the reflog is broken if the object doesn't exist in our hash. So in short, --connectivity-only is broken pretty badly, and will claim that your repository is fine when it's not. Presumably nobody noticed for a few reasons. One is that the embedded test does not actually test the recursive nature of the reachability check. All of the missing objects are still in the index, and we directly check items from the index. This patch modifies the test to delete the index, which shows off breakage (1). Another is that --connectivity-only just skips the initial pass for loose objects. So on a real repository, the packed objects were still checked correctly. But on the flipside, it means that "git fsck --connectivity-only" still checks the sha1 of all of the packed objects, nullifying its original purpose of being a faster git-fsck. And of course the final problem is that the bug only shows up when there _is_ corruption, which is rare. So anybody running "git fsck --connectivity-only" proactively would assume it was being thorough, when it was not. One possibility for fixing this is to find all of the spots that rely on HAS_OBJ and tweak them for the connectivity-only case. But besides the risk that we might miss a spot (and I found three already, corresponding to the three bugs above), there are other parts of fsck that _can't_ work without a full list of objects. E.g., the list of dangling objects. Instead, let's make the connectivity-only case look more like the normal case. Rather than skip the initial pass completely, we'll do an abbreviated one that sets up the HAS_OBJ flag for each object, without actually loading the object data. That's simple and fast, and we don't have to care about the connectivity_only flag in the rest of the code at all. While we're at it, let's make sure we treat loose and packed objects the same (i.e., setting up dummy objects for both and skipping the actual sha1 check). That makes the connectivity-only check actually fast on a real repo (40 seconds versus 180 seconds on my copy of linux.git). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 22:32:57 +01:00
blob=$(echo unrelated | git hash-object -w --stdin) &&
t1450: use "mv -f" within loose object directory The loose objects are created with mode 0444. That doesn't prevent them being overwritten by rename(), but some versions of "mv" will be extra careful and prompt the user, even without "-i". Reportedly macOS does this, at least in the Travis builds. The prompt reads from /dev/null, defaulting to "no", and the object isn't moved. Then to make matters even more interesting, it still returns "0" and the rest of the test proceeds, but with a broken setup. We can work around it by using "mv -f" to override the prompt. This should work as it's already used in t5504 for the same purpose. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-24 14:27:49 +01:00
mv -f $(sha1_file $blob) $empty &&
fsck: prepare dummy objects for --connectivity-check Normally fsck makes a pass over all objects to check their integrity, and then follows up with a reachability check to make sure we have all of the referenced objects (and to know which ones are dangling). The latter checks for the HAS_OBJ flag in obj->flags to see if we found the object in the first pass. Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`, 2015-06-22) taught fsck to skip the initial pass, and to fallback to has_sha1_file() instead of the HAS_OBJ check. However, it converted only one HAS_OBJ check to use has_sha1_file(). But there are many other places in builtin/fsck.c that assume that the flag is set (or that lookup_object() will return an object at all). This leads to several bugs with --connectivity-only: 1. mark_object() will not queue objects for examination, so recursively following links from commits to trees, etc, did nothing. I.e., we were checking the reachability of hardly anything at all. 2. When a set of heads is given on the command-line, we use lookup_object() to see if they exist. But without the initial pass, we assume nothing exists. 3. When loading reflog entries, we do a similar lookup_object() check, and complain that the reflog is broken if the object doesn't exist in our hash. So in short, --connectivity-only is broken pretty badly, and will claim that your repository is fine when it's not. Presumably nobody noticed for a few reasons. One is that the embedded test does not actually test the recursive nature of the reachability check. All of the missing objects are still in the index, and we directly check items from the index. This patch modifies the test to delete the index, which shows off breakage (1). Another is that --connectivity-only just skips the initial pass for loose objects. So on a real repository, the packed objects were still checked correctly. But on the flipside, it means that "git fsck --connectivity-only" still checks the sha1 of all of the packed objects, nullifying its original purpose of being a faster git-fsck. And of course the final problem is that the bug only shows up when there _is_ corruption, which is rare. So anybody running "git fsck --connectivity-only" proactively would assume it was being thorough, when it was not. One possibility for fixing this is to find all of the spots that rely on HAS_OBJ and tweak them for the connectivity-only case. But besides the risk that we might miss a spot (and I found three already, corresponding to the three bugs above), there are other parts of fsck that _can't_ work without a full list of objects. E.g., the list of dangling objects. Instead, let's make the connectivity-only case look more like the normal case. Rather than skip the initial pass completely, we'll do an abbreviated one that sets up the HAS_OBJ flag for each object, without actually loading the object data. That's simple and fast, and we don't have to care about the connectivity_only flag in the rest of the code at all. While we're at it, let's make sure we treat loose and packed objects the same (i.e., setting up dummy objects for both and skipping the actual sha1 check). That makes the connectivity-only check actually fast on a real repo (40 seconds versus 180 seconds on my copy of linux.git). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 22:32:57 +01:00
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 17:27:12 +02:00
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: prepare dummy objects for --connectivity-check Normally fsck makes a pass over all objects to check their integrity, and then follows up with a reachability check to make sure we have all of the referenced objects (and to know which ones are dangling). The latter checks for the HAS_OBJ flag in obj->flags to see if we found the object in the first pass. Commit 02976bf85 (fsck: introduce `git fsck --connectivity-only`, 2015-06-22) taught fsck to skip the initial pass, and to fallback to has_sha1_file() instead of the HAS_OBJ check. However, it converted only one HAS_OBJ check to use has_sha1_file(). But there are many other places in builtin/fsck.c that assume that the flag is set (or that lookup_object() will return an object at all). This leads to several bugs with --connectivity-only: 1. mark_object() will not queue objects for examination, so recursively following links from commits to trees, etc, did nothing. I.e., we were checking the reachability of hardly anything at all. 2. When a set of heads is given on the command-line, we use lookup_object() to see if they exist. But without the initial pass, we assume nothing exists. 3. When loading reflog entries, we do a similar lookup_object() check, and complain that the reflog is broken if the object doesn't exist in our hash. So in short, --connectivity-only is broken pretty badly, and will claim that your repository is fine when it's not. Presumably nobody noticed for a few reasons. One is that the embedded test does not actually test the recursive nature of the reachability check. All of the missing objects are still in the index, and we directly check items from the index. This patch modifies the test to delete the index, which shows off breakage (1). Another is that --connectivity-only just skips the initial pass for loose objects. So on a real repository, the packed objects were still checked correctly. But on the flipside, it means that "git fsck --connectivity-only" still checks the sha1 of all of the packed objects, nullifying its original purpose of being a faster git-fsck. And of course the final problem is that the bug only shows up when there _is_ corruption, which is rare. So anybody running "git fsck --connectivity-only" proactively would assume it was being thorough, when it was not. One possibility for fixing this is to find all of the spots that rely on HAS_OBJ and tweak them for the connectivity-only case. But besides the risk that we might miss a spot (and I found three already, corresponding to the three bugs above), there are other parts of fsck that _can't_ work without a full list of objects. E.g., the list of dangling objects. Instead, let's make the connectivity-only case look more like the normal case. Rather than skip the initial pass completely, we'll do an abbreviated one that sets up the HAS_OBJ flag for each object, without actually loading the object data. That's simple and fast, and we don't have to care about the connectivity_only flag in the rest of the code at all. While we're at it, let's make sure we treat loose and packed objects the same (i.e., setting up dummy objects for both and skipping the actual sha1 check). That makes the connectivity-only check actually fast on a real repo (40 seconds versus 180 seconds on my copy of linux.git). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-17 22:32:57 +01:00
test_expect_success 'fsck --connectivity-only with explicit head' '
rm -rf connectivity-only &&
git init connectivity-only &&
(
cd connectivity-only &&
test_commit foo &&
rm -f .git/index &&
tree=$(git rev-parse HEAD^{tree}) &&
remove_object $(git rev-parse HEAD:foo.t) &&
test_must_fail git fsck --connectivity-only $tree
)
'
fsck: optionally show more helpful info for broken links When reporting broken links between commits/trees/blobs, it would be quite helpful at times if the user would be told how the object is supposed to be reachable. With the new --name-objects option, git-fsck will try to do exactly that: name the objects in a way that shows how they are reachable. For example, when some reflog got corrupted and a blob is missing that should not be, the user might want to remove the corresponding reflog entry. This option helps them find that entry: `git fsck` will now report something like this: broken link from tree b5eb6ff... (refs/stash@{<date>}~37:) to blob ec5cf80... Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-17 13:00:02 +02:00
test_expect_success 'fsck --name-objects' '
rm -rf name-objects &&
git init name-objects &&
(
cd name-objects &&
test_commit julius caesar.t &&
test_commit augustus &&
test_commit caesar &&
t1450: refactor loose-object removal Commit 90cf590f5 (fsck: optionally show more helpful info for broken links, 2016-07-17) added a remove_loose_object() helper, but we already had a remove_object() helper that did the same thing. Let's combine these into one. The implementations had a few subtle differences, so I've tried to take the best of both: - the original used "sed", but the newer version avoids spawning an extra process - the original processed "$*", which was nonsense, as it assumed only a single sha1. Use "$1" to make that more clear. - the newer version ran an extra rev-parse, but it was not necessary; it's sole caller already converted the argument into a raw sha1 - the original used "rm -f", whereas the new one uses "rm". The latter is better because it may notice a bug or other unexpected failure in the test. (The original does check that the object exists before we remove it, which is good, but that's a subset of the possible unexpected conditions). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 18:54:10 +01:00
remove_object $(git rev-parse julius:caesar.t) &&
fsck: optionally show more helpful info for broken links When reporting broken links between commits/trees/blobs, it would be quite helpful at times if the user would be told how the object is supposed to be reachable. With the new --name-objects option, git-fsck will try to do exactly that: name the objects in a way that shows how they are reachable. For example, when some reflog got corrupted and a blob is missing that should not be, the user might want to remove the corresponding reflog entry. This option helps them find that entry: `git fsck` will now report something like this: broken link from tree b5eb6ff... (refs/stash@{<date>}~37:) to blob ec5cf80... Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-17 13:00:02 +02:00
test_must_fail git fsck --name-objects >out &&
tree=$(git rev-parse --verify julius:) &&
t1450: use egrep for regexp "alternation" GNU grep allows "\(A\|B\)" as alternation in BRE, but this is an extension not understood by some other implementations of grep (Michael Kebe reported an breakage on Solaris). Rewrite the offending test to ERE and use egrep instead. Noticed-by: Michael Kebe <michael.kebe@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-28 19:17:04 +02:00
egrep "$tree \((refs/heads/master|HEAD)@\{[0-9]*\}:" out
fsck: optionally show more helpful info for broken links When reporting broken links between commits/trees/blobs, it would be quite helpful at times if the user would be told how the object is supposed to be reachable. With the new --name-objects option, git-fsck will try to do exactly that: name the objects in a way that shows how they are reachable. For example, when some reflog got corrupted and a blob is missing that should not be, the user might want to remove the corresponding reflog entry. This option helps them find that entry: `git fsck` will now report something like this: broken link from tree b5eb6ff... (refs/stash@{<date>}~37:) to blob ec5cf80... Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-17 13:00:02 +02:00
)
'
sha1_file: fix error message for alternate objects When we fail to open a corrupt loose object, we report an error and mention the filename via sha1_file_name(). However, that function will always give us a path in the local repository, whereas the corrupt object may have come from an alternate. The result is a very misleading error message. Teach the open_sha1_file() and stat_sha1_file() helpers to pass back the path they found, so that we can report it correctly. Note that the pointers we return go to static storage (e.g., from sha1_file_name()), which is slightly dangerous. However, these helpers are static local helpers, and the names are used for immediately generating error messages. The simplicity is an acceptable tradeoff for the danger. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 18:54:39 +01:00
test_expect_success 'alternate objects are correctly blamed' '
test_when_finished "rm -rf alt.git .git/objects/info/alternates" &&
git init --bare alt.git &&
echo "../../alt.git/objects" >.git/objects/info/alternates &&
mkdir alt.git/objects/12 &&
>alt.git/objects/12/34567890123456789012345678901234567890 &&
test_must_fail git fsck >out 2>&1 &&
grep alt.git out
'
t1450: test fsck of packed objects The code paths in fsck for packed and loose objects are quite different, and it is not immediately obvious that the packed case behaves well. In particular: 1. The fsck_loose() function always returns "0" to tell the iterator to keep checking more objects. Whereas fsck_obj_buffer() (which handles packed objects) returns -1. This is OK, because the callback machinery for verify_pack() does not stop when it sees a non-zero return. 2. The fsck_loose() function sets the ERROR_OBJECT bit when fsck_obj() fails, whereas fsck_obj_buffer() sets it only when it sees a corrupt object. This turns out not to matter. We don't actually do anything with this bit except exit the program with a non-zero code, and that is handled already by the non-zero return from the function. So there are no bugs here, but it was certainly confusing to me. And we do not test either of the properties in t1450 (neither that a non-corruption error will caused a non-zero exit for a packed object, nor that we keep going after seeing the first error). Let's test both of those conditions, so that we'll notice if any of those assumptions becomes invalid. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 18:55:55 +01:00
test_expect_success 'fsck errors in packed objects' '
git cat-file commit HEAD >basis &&
sed "s/</one/" basis >one &&
sed "s/</foo/" basis >two &&
one=$(git hash-object -t commit -w one) &&
two=$(git hash-object -t commit -w two) &&
pack=$(
{
echo $one &&
echo $two
} | git pack-objects .git/objects/pack/pack
) &&
test_when_finished "rm -f .git/objects/pack/pack-$pack.*" &&
remove_object $one &&
remove_object $two &&
test_must_fail git fsck 2>out &&
grep "error in commit $one.* - bad name" out &&
grep "error in commit $two.* - bad name" out &&
! grep corrupt out
'
tests: ensure fsck fails on corrupt packfiles t1450-fsck.sh does not have a test that checks fsck's behavior when a packfile is invalid. It does have a test for when an object in a packfile is invalid, but in that test, the packfile itself is valid. Add such a test. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-28 22:08:02 +02:00
test_expect_success 'fsck fails on corrupt packfile' '
hsh=$(git commit-tree -m mycommit HEAD^{tree}) &&
pack=$(echo $hsh | git pack-objects .git/objects/pack/pack) &&
# Corrupt the first byte of the first object. (It contains 3 type bits,
# at least one of which is not zero, so setting the first byte to 0 is
# sufficient.)
chmod a+w .git/objects/pack/pack-$pack.pack &&
printf '\0' | dd of=.git/objects/pack/pack-$pack.pack bs=1 conv=notrunc seek=12 &&
test_when_finished "rm -f .git/objects/pack/pack-$pack.*" &&
remove_object $hsh &&
test_must_fail git fsck 2>out &&
test_i18ngrep "checksum mismatch" out
'
fsck: parse loose object paths directly When we iterate over the list of loose objects to check, we get the actual path of each object. But we then throw it away and pass just the sha1 to fsck_sha1(), which will do a fresh lookup. Usually it would find the same object, but it may not if an object exists both as a loose and a packed object. We may end up checking the packed object twice, and never look at the loose one. In practice this isn't too terrible, because if fsck doesn't complain, it means you have at least one good copy. But since the point of fsck is to look for corruption, we should be thorough. The new read_loose_object() interface can help us get the data from disk, and then we replace parse_object() with parse_object_buffer(). As a bonus, our error messages now mention the path to a corrupted object, which should make it easier to track down errors when they do happen. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 18:59:44 +01:00
test_expect_success 'fsck finds problems in duplicate loose objects' '
rm -rf broken-duplicate &&
git init broken-duplicate &&
(
cd broken-duplicate &&
test_commit duplicate &&
# no "-d" here, so we end up with duplicates
git repack &&
# now corrupt the loose copy
file=$(sha1_file "$(git rev-parse HEAD)") &&
rm "$file" &&
echo broken >"$file" &&
test_must_fail git fsck
)
'
fsck: detect trailing garbage in all object types When a loose tree or commit is read by fsck (or any git program), unpack_sha1_rest() checks whether there is extra cruft at the end of the object file, after the zlib data. Blobs that are streamed, however, do not have this check. For normal git operations, it's not a big deal. We know the sha1 and size checked out, so we have the object bytes we wanted. The trailing garbage doesn't affect what we're trying to do. But since the point of fsck is to find corruption or other problems, it should be more thorough. This patch teaches its loose-sha1 reader to detect extra bytes after the zlib stream and complain. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 19:00:25 +01:00
test_expect_success 'fsck detects trailing loose garbage (commit)' '
git cat-file commit HEAD >basis &&
echo bump-commit-sha1 >>basis &&
commit=$(git hash-object -w -t commit basis) &&
file=$(sha1_file $commit) &&
test_when_finished "remove_object $commit" &&
chmod +w "$file" &&
echo garbage >>"$file" &&
test_must_fail git fsck 2>out &&
test_i18ngrep "garbage.*$commit" out
'
t1450: check large blob in trailing-garbage test Commit cce044df7f (fsck: detect trailing garbage in all object types, 2017-01-13) added two tests of trailing garbage in a loose object file: one with a commit and one with a blob. The point of having two is that blobs would follow a different code path that streamed the contents, instead of loading it into a buffer as usual. At the time, merely being a blob was enough to trigger the streaming code path. But since 7ac4f3a007 (fsck: actually fsck blob data, 2018-05-02), we now only stream blobs that are actually large. So since then, the streaming code path is not tested at all for this case. We can restore the original intent of the test by tweaking core.bigFileThreshold to make our small blob seem large. There's no easy way to externally verify that we followed the streaming code path, but I did check before/after using a temporary debug statement. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31 00:18:51 +01:00
test_expect_success 'fsck detects trailing loose garbage (large blob)' '
fsck: detect trailing garbage in all object types When a loose tree or commit is read by fsck (or any git program), unpack_sha1_rest() checks whether there is extra cruft at the end of the object file, after the zlib data. Blobs that are streamed, however, do not have this check. For normal git operations, it's not a big deal. We know the sha1 and size checked out, so we have the object bytes we wanted. The trailing garbage doesn't affect what we're trying to do. But since the point of fsck is to find corruption or other problems, it should be more thorough. This patch teaches its loose-sha1 reader to detect extra bytes after the zlib stream and complain. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 19:00:25 +01:00
blob=$(echo trailing | git hash-object -w --stdin) &&
file=$(sha1_file $blob) &&
test_when_finished "remove_object $blob" &&
chmod +w "$file" &&
echo garbage >>"$file" &&
t1450: check large blob in trailing-garbage test Commit cce044df7f (fsck: detect trailing garbage in all object types, 2017-01-13) added two tests of trailing garbage in a loose object file: one with a commit and one with a blob. The point of having two is that blobs would follow a different code path that streamed the contents, instead of loading it into a buffer as usual. At the time, merely being a blob was enough to trigger the streaming code path. But since 7ac4f3a007 (fsck: actually fsck blob data, 2018-05-02), we now only stream blobs that are actually large. So since then, the streaming code path is not tested at all for this case. We can restore the original intent of the test by tweaking core.bigFileThreshold to make our small blob seem large. There's no easy way to externally verify that we followed the streaming code path, but I did check before/after using a temporary debug statement. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31 00:18:51 +01:00
test_must_fail git -c core.bigfilethreshold=5 fsck 2>out &&
fsck: detect trailing garbage in all object types When a loose tree or commit is read by fsck (or any git program), unpack_sha1_rest() checks whether there is extra cruft at the end of the object file, after the zlib data. Blobs that are streamed, however, do not have this check. For normal git operations, it's not a big deal. We know the sha1 and size checked out, so we have the object bytes we wanted. The trailing garbage doesn't affect what we're trying to do. But since the point of fsck is to find corruption or other problems, it should be more thorough. This patch teaches its loose-sha1 reader to detect extra bytes after the zlib stream and complain. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-13 19:00:25 +01:00
test_i18ngrep "garbage.*$blob" out
'
check_stream_sha1(): handle input underflow This commit fixes an infinite loop when fscking large truncated loose objects. The check_stream_sha1() function takes an mmap'd loose object buffer and streams 4k of output at a time, checking its sha1. The loop quits when we've output enough bytes (we know the size from the object header), or when zlib tells us anything except Z_OK or Z_BUF_ERROR. The latter is expected because zlib may run out of room in our 4k buffer, and that is how it tells us to process the output and loop again. But Z_BUF_ERROR also covers another case: one in which zlib cannot make forward progress because it needs more _input_. This should never happen in this loop, because though we're streaming the output, we have the entire deflated input available in the mmap'd buffer. But since we don't check this case, we'll just loop infinitely if we do see a truncated object, thinking that zlib is asking for more output space. It's tempting to fix this by checking stream->avail_in as part of the loop condition (and quitting if all of our bytes have been consumed). But that assumes that once zlib has consumed the input, there is nothing left to do. That's not necessarily the case: it may have read our input into its internal state, but still have bytes to output. Instead, let's continue on Z_BUF_ERROR only when we see the case we're expecting: the previous round filled our output buffer completely. If it didn't (and we still saw Z_BUF_ERROR), we know something is wrong and should break out of the loop. The bug comes from commit f6371f9210 (sha1_file: add read_loose_object() function, 2017-01-13), which reimplemented some of the existing loose object functions. So it's worth checking if this bug was inherited from any of those. The answers seems to be no. The two obvious candidates are both OK: 1. unpack_sha1_rest(); this doesn't need to loop on Z_BUF_ERROR at all, since it allocates the expected output buffer in advance (which we can't do since we're explicitly streaming here) 2. check_object_signature(); the streaming path relies on the istream interface, which uses read_istream_loose() for this case. That function uses a similar "is our output buffer full" check with Z_BUF_ERROR (which is where I stole it from for this patch!) Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31 00:23:12 +01:00
test_expect_success 'fsck detects truncated loose object' '
# make it big enough that we know we will truncate in the data
# portion, not the header
Adjust for 2.19.x series * jk/detect-truncated-zlib-input cat-file: handle streaming failures consistently check_stream_sha1(): handle input underflow t1450: check large blob in trailing-garbage test
2018-10-31 05:12:12 +01:00
test-tool genrandom truncate 4096 >file &&
check_stream_sha1(): handle input underflow This commit fixes an infinite loop when fscking large truncated loose objects. The check_stream_sha1() function takes an mmap'd loose object buffer and streams 4k of output at a time, checking its sha1. The loop quits when we've output enough bytes (we know the size from the object header), or when zlib tells us anything except Z_OK or Z_BUF_ERROR. The latter is expected because zlib may run out of room in our 4k buffer, and that is how it tells us to process the output and loop again. But Z_BUF_ERROR also covers another case: one in which zlib cannot make forward progress because it needs more _input_. This should never happen in this loop, because though we're streaming the output, we have the entire deflated input available in the mmap'd buffer. But since we don't check this case, we'll just loop infinitely if we do see a truncated object, thinking that zlib is asking for more output space. It's tempting to fix this by checking stream->avail_in as part of the loop condition (and quitting if all of our bytes have been consumed). But that assumes that once zlib has consumed the input, there is nothing left to do. That's not necessarily the case: it may have read our input into its internal state, but still have bytes to output. Instead, let's continue on Z_BUF_ERROR only when we see the case we're expecting: the previous round filled our output buffer completely. If it didn't (and we still saw Z_BUF_ERROR), we know something is wrong and should break out of the loop. The bug comes from commit f6371f9210 (sha1_file: add read_loose_object() function, 2017-01-13), which reimplemented some of the existing loose object functions. So it's worth checking if this bug was inherited from any of those. The answers seems to be no. The two obvious candidates are both OK: 1. unpack_sha1_rest(); this doesn't need to loop on Z_BUF_ERROR at all, since it allocates the expected output buffer in advance (which we can't do since we're explicitly streaming here) 2. check_object_signature(); the streaming path relies on the istream interface, which uses read_istream_loose() for this case. That function uses a similar "is our output buffer full" check with Z_BUF_ERROR (which is where I stole it from for this patch!) Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-31 00:23:12 +01:00
blob=$(git hash-object -w file) &&
file=$(sha1_file $blob) &&
test_when_finished "remove_object $blob" &&
test_copy_bytes 1024 <"$file" >tmp &&
rm "$file" &&
mv -f tmp "$file" &&
# check both regular and streaming code paths
test_must_fail git fsck 2>out &&
test_i18ngrep corrupt.*$blob out &&
test_must_fail git -c core.bigfilethreshold=128 fsck 2>out &&
test_i18ngrep corrupt.*$blob out
'
fsck: report trees as dangling After checking connectivity, fsck looks through the list of any objects we've seen mentioned, and reports unreachable and un-"used" ones as dangling. However, it skips any object which is not marked as "parsed", as that is an object that we _don't_ have (but that somebody mentioned). Since 6e454b9a3 (clear parsed flag when we free tree buffers, 2013-06-05), that flag can't be relied on, and the correct method is to check the HAS_OBJ flag. The cleanup in that commit missed this callsite, though. As a result, we would generally fail to report dangling trees. We never noticed because there were no tests in this area (for trees or otherwise). Let's add some. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-16 22:25:35 +01:00
# for each of type, we have one version which is referenced by another object
# (and so while unreachable, not dangling), and another variant which really is
# dangling.
test_expect_success 'fsck notices dangling objects' '
git init dangling &&
(
cd dangling &&
blob=$(echo not-dangling | git hash-object -w --stdin) &&
dblob=$(echo dangling | git hash-object -w --stdin) &&
tree=$(printf "100644 blob %s\t%s\n" $blob one | git mktree) &&
dtree=$(printf "100644 blob %s\t%s\n" $blob two | git mktree) &&
commit=$(git commit-tree $tree) &&
dcommit=$(git commit-tree -p $commit $tree) &&
cat >expect <<-EOF &&
dangling blob $dblob
dangling commit $dcommit
dangling tree $dtree
EOF
git fsck >actual &&
# the output order is non-deterministic, as it comes from a hash
sort <actual >actual.sorted &&
test_cmp expect actual.sorted
)
'
fsck: tighten error-checks of "git fsck <head>" Instead of checking reachability from the refs, you can ask fsck to check from a particular set of heads. However, the error checking here is quite lax. In particular: 1. It claims lookup_object() will report an error, which is not true. It only does a hash lookup, and the user has no clue that their argument was skipped. 2. When either the name or sha1 cannot be resolved, we continue to exit with a successful error code, even though we didn't check what the user asked us to. This patch fixes both of these cases. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-16 22:33:29 +01:00
test_expect_success 'fsck $name notices bogus $name' '
test_must_fail git fsck bogus &&
t: switch $_z40 to $ZERO_OID Switch all uses of $_z40 to $ZERO_OID so that they work correctly with larger hashes. This commit was created by using the following sed command to modify all files in the t directory except t/test-lib.sh: sed -i 's/\$_z40/$ZERO_OID/g' Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-13 04:24:13 +02:00
test_must_fail git fsck $ZERO_OID
fsck: tighten error-checks of "git fsck <head>" Instead of checking reachability from the refs, you can ask fsck to check from a particular set of heads. However, the error checking here is quite lax. In particular: 1. It claims lookup_object() will report an error, which is not true. It only does a hash lookup, and the user has no clue that their argument was skipped. 2. When either the name or sha1 cannot be resolved, we continue to exit with a successful error code, even though we didn't check what the user asked us to. This patch fixes both of these cases. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-16 22:33:29 +01:00
'
fsck: do not fallback "git fsck <bogus>" to "git fsck" Since fsck tries to continue as much as it can after seeing an error, we still do the reachability check even if some heads we were given on the command-line are bogus. But if _none_ of the heads is is valid, we fallback to checking all refs and the index, which is not what the user asked for at all. Instead of checking "heads", the number of successful heads we got, check "argc" (which we know only has non-options in it, because parse_options removed the others). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-16 22:34:21 +01:00
test_expect_success 'bogus head does not fallback to all heads' '
# set up a case that will cause a reachability complaint
echo to-be-deleted >foo &&
git add foo &&
blob=$(git rev-parse :foo) &&
test_when_finished "git rm --cached foo" &&
remove_object $blob &&
t: switch $_z40 to $ZERO_OID Switch all uses of $_z40 to $ZERO_OID so that they work correctly with larger hashes. This commit was created by using the following sed command to modify all files in the t directory except t/test-lib.sh: sed -i 's/\$_z40/$ZERO_OID/g' Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-13 04:24:13 +02:00
test_must_fail git fsck $ZERO_OID >out 2>&1 &&
fsck: do not fallback "git fsck <bogus>" to "git fsck" Since fsck tries to continue as much as it can after seeing an error, we still do the reachability check even if some heads we were given on the command-line are bogus. But if _none_ of the heads is is valid, we fallback to checking all refs and the index, which is not what the user asked for at all. Instead of checking "heads", the number of successful heads we got, check "argc" (which we know only has non-options in it, because parse_options removed the others). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-16 22:34:21 +01:00
! grep $blob out
'
t1450: avoid use of "sed" on the index, which is a binary file The previous step added a path zzzzzzzz to the index, and then used "sed" to replace this string to yyyyyyyy to create a test case where the checksum at the end of the file does not match the contents. Unfortunately, use of "sed" on a non-text file is not portable. Instead, use a Perl script that seeks to the end and modifies the last byte of the file (where we _know_ stores the trailing checksum). Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-25 20:41:09 +02:00
# Corrupt the checksum on the index.
# Add 1 to the last byte in the SHA.
corrupt_index_checksum () {
perl -w -e '
use Fcntl ":seek";
open my $fh, "+<", ".git/index" or die "open: $!";
binmode $fh;
seek $fh, -1, SEEK_END or die "seek: $!";
read $fh, my $in_byte, 1 or die "read: $!";
$in_value = unpack("C", $in_byte);
$out_value = ($in_value + 1) & 255;
$out_byte = pack("C", $out_value);
seek $fh, -1, SEEK_END or die "seek: $!";
print $fh $out_byte;
close $fh or die "close: $!";
'
}
# Corrupt the checksum on the index and then
# verify that only fsck notices.
read-cache: force_verify_index_checksum Teach git to skip verification of the SHA1-1 checksum at the end of the index file in verify_hdr() which is called from read_index() unless the "force_verify_index_checksum" global variable is set. Teach fsck to force this verification. The checksum verification is for detecting disk corruption, and for small projects, the time it takes to compute SHA-1 is not that significant, but for gigantic repositories this calculation adds significant time to every command. These effect can be seen using t/perf/p0002-read-cache.sh: Test HEAD~1 HEAD -------------------------------------------------------------------------------------- 0002.1: read_cache/discard_cache 1000 times 0.66(0.44+0.20) 0.30(0.27+0.02) -54.5% Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-14 22:32:21 +02:00
test_expect_success 'detect corrupt index file in fsck' '
cp .git/index .git/index.backup &&
test_when_finished "mv .git/index.backup .git/index" &&
t1450: avoid use of "sed" on the index, which is a binary file The previous step added a path zzzzzzzz to the index, and then used "sed" to replace this string to yyyyyyyy to create a test case where the checksum at the end of the file does not match the contents. Unfortunately, use of "sed" on a non-text file is not portable. Instead, use a Perl script that seeks to the end and modifies the last byte of the file (where we _know_ stores the trailing checksum). Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-25 20:41:09 +02:00
corrupt_index_checksum &&
test_must_fail git fsck --cache 2>errors &&
grep "bad index file" errors
read-cache: force_verify_index_checksum Teach git to skip verification of the SHA1-1 checksum at the end of the index file in verify_hdr() which is called from read_index() unless the "force_verify_index_checksum" global variable is set. Teach fsck to force this verification. The checksum verification is for detecting disk corruption, and for small projects, the time it takes to compute SHA-1 is not that significant, but for gigantic repositories this calculation adds significant time to every command. These effect can be seen using t/perf/p0002-read-cache.sh: Test HEAD~1 HEAD -------------------------------------------------------------------------------------- 0002.1: read_cache/discard_cache 1000 times 0.66(0.44+0.20) 0.30(0.27+0.02) -54.5% Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-14 22:32:21 +02:00
'
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 09:33:00 +01:00
test_done
Reference in New Issue Copy Permalink