summaryrefslogtreecommitdiff
path: root/t/t5504-fetch-receive-strict.sh
AgeCommit message (Collapse)AuthorFilesLines
2017-01-07don't use test_must_fail with grepLibravatar Pranit Bauva1-1/+1
test_must_fail should only be used for testing git commands. To test the failure of other commands use `!`. Reported-by: Stefan Beller <sbeller@google.com> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-18test-lib.sh: introduce and use $EMPTY_TREELibravatar Nguyễn Thái Ngọc Duy1-2/+2
This is a special SHA1. Let's keep it at one place, easier to replace later when the hash change comes, easier to recognize. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-20t5504: drop sigpipe=ok from push testsLibravatar Jeff King1-6/+4
These were added by 8bf4bec (add "ok=sigpipe" to test_must_fail and use it to fix flaky tests, 2015-11-27) because we would racily die via SIGPIPE when the pack was rejected by the other side. But since we have recently de-flaked send-pack, we should be able to tighten up these tests (including re-adding the expected output checks). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-25t5504: handle expected output from SIGPIPE deathLibravatar Jeff King1-1/+4
Commit 8bf4bec (add "ok=sigpipe" to test_must_fail and use it to fix flaky tests, 2015-11-27) taught t5504 to handle "git push" racily exiting with SIGPIPE rather than failing. However, one of the tests checks the output of the command, as well. In the SIGPIPE case, we will not have produced any output. If we want the test to be truly non-flaky, we have to accept either output. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-28add "ok=sigpipe" to test_must_fail and use it to fix flaky testsLibravatar Lars Schneider1-3/+2
t5516 "75 - deny fetch unreachable SHA1, allowtipsha1inwant=true" is flaky in the following case: 1. remote upload-pack finds out "not our ref" 2. remote sends a response and closes the pipe 3. fetch-pack still tries to write commands to the remote upload-pack 4. write call in wrapper.c dies with SIGPIPE The test is flaky because the sending fetch-pack may or may not have finished writing its output by step (3). If it did, then we see a closed pipe on the next read() call. If it didn't, then we get the SIGPIPE from step (4) above. Both are fine, but the latter fools test_must_fail. t5504 "9 - push with transfer.fsckobjects" is flaky, too, and returns SIGPIPE once in a while. I had to remove the final "To dst..." output check because there is no output if the process dies with SIGPIPE. Accept such a death-with-sigpipe also as OK when we are expecting a failure. Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Jeff King <peff@peff.net>
2015-06-23fsck: git receive-pack: support excluding objects from fsck'ingLibravatar Johannes Schindelin1-0/+12
The optional new config option `receive.fsck.skipList` specifies the path to a file listing the names, i.e. SHA-1s, one per line, of objects that are to be ignored by `git receive-pack` when `receive.fsckObjects = true`. This is extremely handy in case of legacy repositories where it would cause more pain to change incorrect objects than to live with them (e.g. a duplicate 'author' line in an early commit object). The intended use case is for server administrators to inspect objects that are reported by `git push` as being too problematic to enter the repository, and to add the objects' SHA-1 to a (preferably sorted) file when the objects are legitimate, i.e. when it is determined that those problematic objects should be allowed to enter the server. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-23fsck: optionally ignore specific fsck issues completelyLibravatar Johannes Schindelin1-1/+8
An fsck issue in a legacy repository might be so common that one would like not to bother the user with mentioning it at all. With this change, that is possible by setting the respective message type to "ignore". This change "abuses" the missingEmail=warn test to verify that "ignore" is also accepted and works correctly. And while at it, it makes sure that multiple options work, too (they are passed to unpack-objects or index-pack as a comma-separated list via the --strict=... command-line option). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-23fsck: disallow demoting grave fsck errors to warningsLibravatar Johannes Schindelin1-0/+11
Some kinds of errors are intrinsically unrecoverable (e.g. errors while uncompressing objects). It does not make sense to allow demoting them to mere warnings. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-23fsck: add a simple test for receive.fsck.<msg-id>Libravatar Johannes Schindelin1-0/+21
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-21receive-pack: drop "n/a" on unpacker errorsLibravatar Jeff King1-1/+1
The output from git push currently looks like this: $ git push dest HEAD fatal: [some message from index-pack] error: unpack failed: index-pack abnormal exit To dest ! [remote rejected] HEAD -> master (n/a (unpacker error)) That n/a is meant to be "the per-ref status is not available" but the nested parentheses just make it look ugly. Let's turn the final line into just: ! [remote rejected] HEAD -> master (unpacker error) Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-13do not override receive-pack errorsLibravatar Clemens Buchacher1-4/+18
Receive runs rev-list --verify-objects in order to detect missing objects. However, such errors are ignored and overridden later. Instead, consequently ignore all update commands for which an error has already been detected. Some tests in t5504 are obsoleted by this change, because invalid objects are detected even if fsck is not enabled. Instead, they now test for different error messages depending on whether or not fsck is turned on. A better fix would be to force a corruption that will be detected by fsck but not by rev-list. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05Merge branch 'jc/fetch-verify'Libravatar Junio C Hamano1-2/+2
* jc/fetch-verify: fetch: verify we have everything we need before updating our ref rev-list --verify-object list-objects: pass callback data to show_objects()
2011-09-04test: fetch/receive with fsckobjectsLibravatar Junio C Hamano1-0/+104
Add tests for the new fetch.fsckobjects, and also tests for receive.fsckobjects we have had for quite some time. Signed-off-by: Junio C Hamano <gitster@pobox.com>