summaryrefslogtreecommitdiff
path: root/t/t5300-pack-object.sh
AgeCommit message (Collapse)AuthorFilesLines
2010-05-31tests: use "test_cmp", not "diff", when verifying the resultLibravatar Gary V. Vaughan1-3/+3
In tests, call test_cmp rather than raw diff where possible (i.e. if the output does not go to a pipe), to allow the use of, say, 'cmp' when the default 'diff -u' is not compatible with a vendor diff. When that is not possible, use $DIFF, as set in GIT-BUILD-OPTIONS. Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-08Revert "pack-objects: fix pack generation when using pack_size_limit"Libravatar Nicolas Pitre1-1/+1
This reverts most of commit a2430dde8ceaaaabf05937438249397b883ca77a. That commit made the situation better for repositories with relatively small number of objects. However with many objects and a small pack size limit, the time required to complete the repack tends towards O(n^2), or even much worse with long delta chains. Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-03make --max-pack-size argument to 'git pack-object' count in bytesLibravatar Nicolas Pitre1-6/+8
The value passed to --max-pack-size used to count in MiB which was inconsistent with the corresponding configuration variable as well as other command arguments which are defined to count in bytes with an optional unit suffix. This brings --max-pack-size in line with the rest of Git. Also, in order not to cause havoc with people used to the previous megabyte scale, and because this is a sane thing to do anyway, a minimum size of 1 MiB is enforced to avoid an explosion of pack files. Adjust and extend test suite accordingly. Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-03fix multiple issues with t5300Libravatar Nicolas Pitre1-20/+34
First of all, trying to run 'git verify-pack' on packs produced by the tests using pack.packSizeLimit always failed. After lots of digging and head scratching, it turns out that the preceeding test simulating a SHA1 collision did leave the repository quite confused, impacting subsequent tests. So let's move that destructive test last, and add tests to run verify-pack on the output from those packSizeLimit tests to catch such goofage. Finally, group those packSizeLimit tests together. Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-19t5300, t5302, t5303: Do not use /dev/zeroLibravatar Johannes Sixt1-9/+8
We do not have /dev/zero on Windows. This replaces it by data generated with printf, perl, or echo. Most of the cases do not depend on that the data is a stream of zero bytes, so we use something printable; nor is an unlimited stream of data needed, so we produce only as many bytes as the test cases need. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2009-02-25Merge branch 'jc/maint-1.6.0-pack-directory'Libravatar Junio C Hamano1-0/+17
* jc/maint-1.6.0-pack-directory: Make sure objects/pack exists before creating a new pack
2009-02-25Make sure objects/pack exists before creating a new packLibravatar Junio C Hamano1-0/+17
In a repository created with git older than f49fb35 (git-init-db: create "pack" subdirectory under objects, 2005-06-27), objects/pack/ directory is not created upon initialization. It was Ok because subdirectories are created as needed inside directories init-db creates, and back then, packfiles were recent invention. After the said commit, new codepaths started relying on the presense of objects/pack/ directory in the repository. This was exacerbated with 8b4eb6b (Do not perform cross-directory renames when creating packs, 2008-09-22) that moved the location temporary pack files are created from objects/ directory to objects/pack/ directory, because moving temporary to the final location was done carefully with lazy leading directory creation. Many packfile related operations in such an old repository can fail mysteriously because of this. This commit introduces two helper functions to make things work better. - odb_mkstemp() is a specialized version of mkstemp() to refactor the code and teach it to create leading directories as needed; - odb_pack_keep() refactors the code to create a ".keep" file while create leading directories as needed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-12Merge branch 'maint'Libravatar Junio C Hamano1-0/+6
* maint: Start 1.6.0.5 cycle Fix pack.packSizeLimit and --max-pack-size handling checkout: Fix "initial checkout" detection Remove the period after the git-check-attr summary Conflicts: RelNotes
2008-11-12Fix pack.packSizeLimit and --max-pack-size handlingLibravatar Nicolas Pitre1-0/+6
If the limit was sufficiently low, having a single object written could bust the limit (by design), but caused the remaining allowed size to go negative for subsequent objects, which for an unsigned variable is a rather huge limit. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-18Merge branch 'np/pack'Libravatar Junio C Hamano1-1/+2
* np/pack: t5300: improve SHA1 collision test pack-objects: don't include missing preferred base objects sha1write: don't copy full sized buffers Conflicts: t/t5300-pack-object.sh
2008-09-03Merge branch 'ho/dashless' into maintLibravatar Junio C Hamano1-8/+8
* ho/dashless: tests: use "git xyzzy" form (t7200 - t9001) tests: use "git xyzzy" form (t7000 - t7199) tests: use "git xyzzy" form (t3600 - t6999) tests: use "git xyzzy" form (t0000 - t3599) 'git foo' program identifies itself without dash in die() messages Start conforming code to "git subcmd" style
2008-09-03tests: use "git xyzzy" form (t3600 - t6999)Libravatar Nanako Shiraishi1-8/+8
Converts tests between t3600-t6300. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-02t5300: improve SHA1 collision testLibravatar Nicolas Pitre1-1/+2
Make sure the reason for the command failure is actually due to the detection of SHA1 collision. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-22discard revindex data when pack list changesLibravatar Nicolas Pitre1-0/+6
This is needed to fix verify-pack -v with multiple pack arguments. Also, in theory, revindex data (if any) must be discarded whenever reprepare_packed_git() is called. In practice this is hard to trigger though. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13t/: Use "test_must_fail git" instead of "! git"Libravatar Stephan Beyer1-1/+1
This patch changes every occurrence of "! git" -- with the meaning that a git call has to gracefully fail -- into "test_must_fail git". This is useful to - make sure the test does not fail because of a signal, e.g. SIGSEGV, and - advertise the use of "test_must_fail" for new tests. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-09Merge branch 'mk/unpack-careful'Libravatar Junio C Hamano1-0/+95
* mk/unpack-careful: t5300: add test for "index-pack --strict" receive-pack: allow using --strict mode for unpacking objects unpack-objects: fix --strict handling t5300: add test for "unpack-objects --strict" unpack-objects: prevent writing of inconsistent objects
2008-03-13more tr portability test script fixesLibravatar Jeff King1-1/+1
Dealing with NULs is not always safe with tr. On Solaris, incoming NULs are silently deleted by both the System V and UCB versions of tr. When converting to NULs, the System V version works fine, but the UCB version silently ignores the request to convert the character. This patch changes all instances of tr using NULs to use "perl -pe 'y///'" instead. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-07t5300: add test for "index-pack --strict"Libravatar Martin Koegler1-0/+47
This adds test for indexing packs with --strict option, basically the same as c0e809e (t5300: add test for "unpack-objects --strict") has done for unpack-objects. Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>