summaryrefslogtreecommitdiff
path: root/t/t5300-pack-object.sh
AgeCommit message (Collapse)AuthorFilesLines
2008-03-05unpack-objects: fix --strict handlingLibravatar Junio C Hamano1-1/+1
Earlier attempt (which was reverted) called added_object() (by the way, the function should be renamed to resolve_dependents() --- it is called when we have a complete object data, and is responsible to resolve pending deltified objects that use this object as their delta base object) without updating obj_list[nr].sha1 with the correct value. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-05t5300: add test for "unpack-objects --strict"Libravatar Junio C Hamano1-0/+48
This adds test for unpacking deltified objects with --strict option. - unpacking full trees with --strict should pass; - unpacking only trees with --strict should be rejected due to missing blobs; - unpacking only trees with --strict into an existing repository with necessary blobs should succeed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-09Introduce the config variable pack.packSizeLimitLibravatar Johannes Schindelin1-0/+6
"git pack-objects" has the option --max-pack-size to limit the file size of the packs to a certain amount of bytes. On platforms where the pack file size is limited by filesystem constraints, it is easy to forget this option, and this option does not exist for "git gc" to begin with. So introduce a config variable to set the default maximum, but make this overrideable by the command line. Suggested by Tor Arvid Lund. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01Sane use of test_expect_failureLibravatar Junio C Hamano1-2/+2
Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-17the use of 'tr' in the test suite isn't really portableLibravatar H.Merijn Brand1-1/+1
Some versions of 'tr' only accept octal codes if entered with three digits, and therefor misinterpret the '\0' in the test suite. Some versions of 'tr' reject the (needless) use of character classes. Signed-off-by: H.Merijn Brand <h.m.brand@xs4all.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-14t5300-pack-object.sh: Split the big verify-pack test into smaller parts.Libravatar Johannes Sixt1-16/+18
This makes it easier to spot which of the tests failed. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-36/+36
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-04-22Update tests not to assume that generated packfiles are writable.Libravatar Junio C Hamano1-11/+11
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-06t5300-pack-object.sh: portability issue using /usr/bin/statLibravatar Arjen Laarhoven1-5/+6
In the test 'compare delta flavors', /usr/bin/stat is used to get file size. This isn't portable. There already is a dependency on Perl, use its '-s' operator to get the file size. Signed-off-by: Arjen Laarhoven <arjen@yaph.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-20don't ever allow SHA1 collisions to exist by fetching a packLibravatar Nicolas Pitre1-0/+10
Waaaaaaay back Git was considered to be secure as it never overwrote an object it already had. This was ensured by always unpacking the packfile received over the network (both in fetch and receive-pack) and our already existing logic to not create a loose object for an object we already have. Lately however we keep "large-ish" packfiles on both fetch and push by running them through index-pack instead of unpack-objects. This would let an attacker perform a birthday attack. How? Assume the attacker knows a SHA-1 that has two different data streams. He knows the client is likely to have the "good" one. So he sends the "evil" variant to the other end as part of a "large-ish" packfile. The recipient keeps that packfile, and indexes it. Now since this is a birthday attack there is a SHA-1 collision; two objects exist in the repository with the same SHA-1. They have *very* different data streams. One of them is "evil". Currently the poor recipient cannot tell the two objects apart, short of by examining the timestamp of the packfiles. But lets say the recipient repacks before he realizes he's been attacked. We may wind up packing the "evil" version of the object, and deleting the "good" one. This is made *even more likely* by Junio's recent rearrange_packed_git patch (b867092f). It is extremely unlikely for a SHA1 collisions to occur, but if it ever happens with a remote (hence untrusted) object we simply must not let the fetch succeed. Normally received packs should not contain objects we already have. But when they do we must ensure duplicated objects with the same SHA1 actually contain the same data. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-16[PATCH] add test for OFS_DELTA objectsLibravatar Nicolas Pitre1-6/+65
Make sure pack-objects with --delta-base-offset works fine, and that it actually produces smaller packs as expected. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-16[PATCH] fix t5300-pack-object.shLibravatar Nicolas Pitre1-1/+1
The 'use packed deltified objects' test was flawed as it failed to remove the pack and index from the previous test, effectively preventing the desired pack from being exercised as objects could be found in that other pack instead. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12use 'init' instead of 'init-db' for shipped docs and toolsLibravatar Nicolas Pitre1-3/+3
While 'init-db' still is and probably will always remain a valid git command for obvious backward compatibility reasons, it would be a good idea to move shipped tools and docs to using 'init' instead. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-27Guard a test against wc that pads its output with whitespaceLibravatar Junio C Hamano1-1/+1
Spotted by Johannes. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-26t5300: avoid false failures.Libravatar Junio C Hamano1-1/+7
Johannes found that the test has 1/256 chance of falsely producing an uncorrupted idx file, causing the check to detect corruption fail. Now we have 1/2^160 chance of false failure ;-). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-23check_packed_git_idx(): check integrity of the idx file itself.Libravatar Junio C Hamano1-0/+7
Although pack-check.c had routine to verify the checksum for the pack index file itself, the core did not check it before using it. This is stolen from the patch to tighten packname requirements. Signed-off-by: Junio C Hamano <junkio@cox.net> (cherry picked from 797bd6f490c91c07986382b9f268e0df712cb246 commit)
2005-10-28fix testsuite to tolerate spaces in pathLibravatar Pavel Roskin1-4/+4
This patch allows the testsuite to run properly when the full path to the git sources contains spaces or other symbols that need to be quoted. Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-12Add git-index-pack utilityLibravatar Sergey Vlasov1-0/+18
git-index-pack builds a pack index file for an existing packed archive. With this utility a packed archive which was transferred without the corresponding pack index can be added to objects/pack/ without repacking. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-07Big tool rename.Libravatar Junio C Hamano1-2/+2
As promised, this is the "big tool rename" patch. The primary differences since 0.99.6 are: (1) git-*-script are no more. The commands installed do not have any such suffix so users do not have to remember if something is implemented as a shell script or not. (2) Many command names with 'cache' in them are renamed with 'index' if that is what they mean. There are backward compatibility symblic links so that you and Porcelains can keep using the old names, but the backward compatibility support is expected to be removed in the near future. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-08-11[PATCH] Trapping exit in tests, using return for errorsLibravatar Pavel Roskin1-6/+6
I have noticed that "make test" fails without any explanations when the "merge" utility is missing. I don't think tests should be silent in case of failure. It turned out that the particular test was using "exit" to interrupt the test in case of an error. This caused the whole test script to exit. No further tests would be run even if "--immediate" wasn't specified. No error message was printed. This patch does following: All instances of "exit", "exit 1" and "(exit 1)" in tests have been replaced with "return 1". In fact, "(exit 1)" had no effect. File descriptor 5 is duplicated from file descriptor 1. This is needed to print important error messages from tests. New function test_run_() has been introduced. Any "return" in the test would merely cause that function to return without skipping calls to test_failure_() and test_ok_(). The new function also traps "exit" and treats it like a fatal error (in case somebody reintroduces "exit" in the tests). test_expect_failure() and test_expect_success() check both the result of eval and the return value of test_run_(). If the later is not 0, it's always a failure because it indicates the the test didn't complete. Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-07-04[PATCH] Fixup t/t5300 unit tests broken by ↵Libravatar Jon Seymour1-15/+15
5f3de58ff85c49620ae2a1722d8d4d37c881a054 This patch fixes up the t/t5300 unit tests which were broken by the changes in: Make the name of a pack-file depend on the objects packed there-in. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-29[PATCH] Adjust t5300 test for unpack-objects changeLibravatar Junio C Hamano1-2/+4
It now always read from standard input and rejects non-flag arguments. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-29[PATCH] Add git-verify-pack command.Libravatar Junio C Hamano1-0/+38
Given a list of <pack>.idx files, this command validates the index file and the corresponding .pack file for consistency. This patch also uses the same validation mechanism in fsck-cache when the --full flag is used. During normal operation, sha1_file.c verifies that a given .idx file matches the .pack file by comparing the SHA1 checksum stored in .idx file and .pack file as a minimum sanity check. We may further want to check the pack signature and version when we map the pack, but that would be a separate patch. Earlier, errors to map a pack file was not flagged fatal but led to a random fatal error later. This version explicitly die()s when such an error is detected. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-27Fix another test that broke with the recent git-init-db updateLibravatar Linus Torvalds1-1/+0
t5300-pack-object.sh test 8 expected to have to create the "pack" directory itself, and was unhappy when it already existed.
2005-06-27[PATCH] Teach read_sha1_file() and friends about packed git object store.Libravatar Junio C Hamano1-2/+46
GIT_OBJECT_DIRECTORY and GIT_ALTERNATE_OBJECT_DIRECTORIES can have the "pack" subdirectory that houses "packed GIT" files produced by git-pack-objects (e.g. .git/objects/pack/foo.pack and .git/objects/pack/foo.idx; always store them as pairs). The following functions in sha1_file.c can then read object contents from such packed file: - sha1_object_info() - has_sha1_file() - read_sha1_file() Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26[PATCH] Finish initial cut of git-pack-object/git-unpack-object pair.Libravatar Junio C Hamano1-0/+85
This finishes the initial round of git-pack-object / git-unpack-object pair. They are now good enough to be used as a transport medium: - Fix delta direction in pack-objects; the original was computing delta to create the base object from the object to be squashed, which was quite unfriendly for unpacker ;-). - Add a script to test the very basics. - Implement unpacker for both regular and deltified objects. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>