kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Ævar Arnfjörð Bjarmason	41be8ea223	tests: implicitly skip SYMLINKS tests using <prereq> Change the tests that skipped due to unavailable SYMLINKS support to use the three-arg prereq form of test_expect_success. Now we get an indication of how many tests that need symlinks are being skipped on platforms that don't support them. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Ævar Arnfjörð Bjarmason	fadb5156e4	tests: Skip tests in a way that makes sense under TAP SKIP messages are now part of the TAP plan. A TAP harness now knows why a particular test was skipped and can report that information. The non-TAP harness built into Git's test-lib did nothing special with these messages, and is unaffected by these changes. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jeff King	5dba359124	tests: remove exit after test_done call test_done always exits, so this line is never executed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Johannes Sixt	704a3143d5	Use prerequisite tags to skip tests that depend on symbolic links Many tests depend on that symbolic links work. This introduces a check that sets the prerequisite tag SYMLINKS if the file system supports symbolic links. Since so many tests have to check for this prerequisite, we do the check in test-lib.sh, so that we don't need to repeat the test in many scripts. To check for 'ln -s' failures, you can use a FAT partition on Linux: $ mkdosfs -C git-on-fat 1000000 $ sudo mount -o loop,uid=j6t,gid=users,shortname=winnt git-on-fat /mnt Clone git to /mnt and $ GIT_SKIP_TESTS='t0001.1[34] t0010 t1301 t403[34] t4129.[47] t5701.7 t7701.3 t9100 t9101.26 t9119 t9124.[67] t9200.10 t9600.6' \ make test (These additionally skipped tests depend on POSIX permissions that FAT on Linux does not provide.) Signed-off-by: Johannes Sixt <j6t@kdbg.org>	16 years ago
Junio C Hamano	b67b9612e1	diff.c: output correct index lines for a split diff A patch that changes the filetype (e.g. regular file to symlink) of a path must be split into a deletion event followed by a creation event, which means that we need to have two independent metainfo lines for each. However, the code reused the single set of metainfo lines. As the blob object names recorded on the index lines are usually not used nor validated on the receiving end, this is not an issue with normal use of the resulting patch. However, when accepting a binary patch to delete a blob, git-apply verified that the postimage blob object name on the index line is 0{40}, hence a patch that deletes a regular file blob that records binary contents to create a blob with different filetype (e.g. a symbolic link) failed to apply. "git am -3" also uses the blob object names recorded on the index line, so it would also misbehave when synthesizing a preimage tree. This moves the code to generate metainfo lines around, so that two independent sets of metainfo lines are used for the split halves. Additional tests by Jeff King. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Junio C Hamano	5be60078c9	Rewrite "git-frotz" to "git frotz" This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Eric Wong	8641fb24ee	typechange tests for git apply (currently failing) I've found that git apply is incapable of handling patches involving object type changes to the same path. Of course git itself is perfectly capable of making commits that generate these changes, as it only tracks trees states. It's just that the diffs between them are less useful if they can't be applied. Some of these are rare, but I've hit one of them (file becoming a symlink) recently in real-world usage, and was inspired to find more potential breakages :) I'm not sure when I'll have time to fix these myself and I'm not very familiar with the apply code. So if someone could get some or all of these cases working, they would be my hero :) Some of these are what I would refer to as corner-cases from hell. Most (if not all) other systems fail some of these. In fact, they aren't even capable of representing most of these changes in their histories; much less being able to handle patches to that effect. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago