mirrors/git - Incest Forge: Beyond sex. We incest.

mirrors/git

mirror of https://github.com/git/git.git synced 2024-10-31 22:37:54 +01:00

33 lines

624 B

Bash

Raw Normal View History

builtin/apply.c: report error on failure to recognize input When git apply is passed something that is not a patch, it does not produce an error message or exit with a non-zero status if it was not actually "applying" the patch i.e. --check or --numstat etc were supplied on the command line. Fix this by producing an error when apply fails to find any hunks whatsoever while parsing the patch. This will cause some of the output formats (--numstat, --diffstat, etc) to produce an error when they formerly would have reported zero changes and exited successfully. That seems like the correct behavior though. Failure to recognize the input as a patch should be an error. Plus, add a test. Reported-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2011-12-03 21:35:50 +01:00			`#!/bin/sh`

			`test_description='git apply should exit non-zero with unrecognized input.'`

			`. ./test-lib.sh`

			`test_expect_success 'setup' '`
			`test_commit 1`
			`'`

			`test_expect_success 'apply --check exits non-zero with unrecognized input' '`
			`test_must_fail git apply --check - <<-\EOF`
			`I am not a patch`
			`I look nothing like a patch`
			`git apply must fail`
			`EOF`
			`'`

apply: reject a hunk that does not do anything A hunk like this in a hand-edited patch without correctly adjusting the line counts: @@ -660,2 +660,2 @@ inline struct sk_buff ieee80211_authentic... auth = (struct ieee80211_authentication ) skb_put(skb, sizeof(struct ieee80211_authentication)); - some old text + some new text -- 2.1.0 dev mailing list at the end of the input does not have a good way for us to diagnose it as a corrupt patch. We just read two context lines and discard the remainder as cruft, which we must do in order to ignore the e-mail footer. Notice that the patch does not change anything and signal an error. Note that this fix will not help if the hand-edited hunk header were "@@ -660,3, +660,2" to include the removal. We would just remove the old text without adding the new one, and treat "+ some new text" and everything after that line as trailing cruft. So it is dubious that this patch alone would help very much in practice, but it may be better than nothing. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2015-06-01 21:12:04 +02:00			`test_expect_success 'apply exits non-zero with no-op patch' '`
			`cat >input <<-\EOF &&`
			`diff --get a/1 b/1`
			`index 6696ea4..606eddd 100644`
			`--- a/1`
			`+++ b/1`
			`@@ -1,1 +1,1 @@`
			`1`
			`EOF`
			`test_must_fail git apply --stat input &&`
			`test_must_fail git apply --check input`
			`'`

builtin/apply.c: report error on failure to recognize input When git apply is passed something that is not a patch, it does not produce an error message or exit with a non-zero status if it was not actually "applying" the patch i.e. --check or --numstat etc were supplied on the command line. Fix this by producing an error when apply fails to find any hunks whatsoever while parsing the patch. This will cause some of the output formats (--numstat, --diffstat, etc) to produce an error when they formerly would have reported zero changes and exited successfully. That seems like the correct behavior though. Failure to recognize the input as a patch should be an error. Plus, add a test. Reported-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2011-12-03 21:35:50 +01:00			`test_done`