summaryrefslogtreecommitdiff
path: root/t/t4103-apply-binary.sh
AgeCommit message (Collapse)Author
2008-02-02Sane use of test_expect_failureJunio C Hamano
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-18the use of 'tr' in the test suite isn't really portableH.Merijn Brand
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-07-03Rewrite "git-frotz" to "git frotz"Junio C Hamano
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2006-09-07Make apply --binary a no-op.Junio C Hamano
Historically we did not allow binary patch applied without an explicit permission from the user, and this flag was the way to do so. This makes the flag a no-op by always allowing binary patch application. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-28t4103: fix binary patch application test.Junio C Hamano
The generated binary patch was _not_ binary -- earlier I made the --full-index flag to imply binary patch generation to the diff machinery, but later we made it independent from --binary (although the latter implies the former). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-20tests: make scripts executableJunio C Hamano
just for consistency. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-17tests: binary diff application.Junio C Hamano
This adds more tests to cover cases where binary diff application succeeds. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-17apply: allow-binary-replacement.Junio C Hamano
A new option, --allow-binary-replacement, is introduced. When you feed a diff that records full SHA1 name of pre- and post-image blob on its index line to git-apply with this option, the post-image blob replaces the path if what you have in the working tree matches the pre-image _and_ post-image blob is already available in the object directory. Later we _might_ want to enhance the diff output to also include the full binary data of the post-image, to make this more useful, but this is good enough for local rebasing application. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-16git-apply: fail if a patch cannot be applied.Junio C Hamano
Recently we fixed 'git-apply --stat' not to barf on a binary differences. But it accidentally broke the error detection when we actually attempt to apply them. This commit fixes the problem and adds test cases. Signed-off-by: Junio C Hamano <junkio@cox.net>