kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Björn Gustavsson	24ff4d56cf	apply: Remove the quick rejection test In the next commit, we will make it possible for blank context lines to match beyond the end of the file. That means that a hunk with a preimage that has more lines than present in the file may be possible to successfully apply. Therefore, we must remove the quick rejection test in find_pos(). find_pos() will already work correctly without the quick rejection test, but that might not be obvious. Therefore, comment the test for handling out-of-range line numbers in find_pos() and cast the "line" variable to the same (unsigned) type as img->nr. What are performance implications of removing the quick rejection test? It can only help "git apply" to reject a patch faster. For example, if I have a file with one million lines and a patch that removes slightly more than 50 percent of the lines and try to apply that patch twice, the second attempt will fail slightly faster with the test than without (based on actual measurements). However, there is the pathological case of a patch with many more context lines than the default three, and applying that patch using "git apply -C1". Without the rejection test, the running time will be roughly proportional to the number of context lines times the size of the file. That could be handled by writing a more complicated rejection test (it would have to count the number of blanks at the end of the preimage), but I don't find that worth doing until there is a real-world use case that would benfit from it. It would be possible to keep the quick rejection test if --whitespace=fix is not given, but I don't like that from a testing point of view. Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Junio C Hamano	ed0f47a8c4	git-apply: Loosen "match_beginning" logic Even after a handfle attempts, match_beginning logic still has corner cases: `1bf1a85` (apply: treat EOF as proper context., 2006-05-23) `65aadb9` (apply: force matching at the beginning., 2006-05-24) `4be6096` (apply --unidiff-zero: loosen sanity checks ..., 2006-09-17) `ee5a317` (Fix "git apply" to correctly enforce "match ..., 2008-04-06) This is a tricky piece of code. We still incorrectly enforce "match_beginning" for -U0 matches. I noticed this while trying out an example sequence from Clemens Buchacher: $ echo a >victim $ git add victim $ echo b >>victim $ git diff -U0 >patch $ cat patch diff --git i/victim w/victim index 7898192..422c2b7 100644 --- i/victim +++ w/victim @@ -1,0 +2 @@ a +b $ git apply --cached --unidiff-zero <patch $ git show :victim b a The change inserts a new line before the second line, but we insist it to be applied at the beginning. As the result, the code refuses to apply it at the original offset, and we end up adding the line at the beginning. Updates to the test script are by Clemens Buchacher. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	3af828634f	tests: do not use implicit "git diff --no-index" As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	ee5a317e01	Fix "git apply" to correctly enforce "match at the beginning" An earlier commit `4be6096` (apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches, 2006-09-17) made match_beginning and match_end computed incorrectly. If a hunk inserts at the beginning, old position recorded at the hunk is line 0, and if a hunk changes at the beginning, it is line 1. The new test added to t4104 exposes that the old code did not insist on matching at the beginning for a patch to add a line to an empty file. An even older `65aadb9` (apply: force matching at the beginning., 2006-05-24) was equally wrong in that it tried to take hints from the number of leading context lines, to decide if the hunk must match at the beginning, but we can just look at the line number in the hunk to decide. Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 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
Johannes Schindelin	5bd74506cd	Get rid of the dependency to GNU diff in the tests Now that "git diff" handles stdin and relative paths outside the working tree correctly, we can convert all instances of "diff -u" to "git diff". This commit is really the result of $ perl -pi.bak -e 's/diff -u/git diff/' $(git grep -l "diff -u" t/) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net> (cherry picked from commit c699a40d68215c7e44a5b26117a35c8a56fbd387)	18 years ago
Junio C Hamano	4be609625e	apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches In "git-apply", we have a few sanity checks and heuristics that expects that the patch fed to us is a unified diff with at least one line of context. * When there is no leading context line in a hunk, the hunk must apply at the beginning of the preimage. Similarly, no trailing context means that the hunk is anchored at the end. * We learn a patch deletes the file from a hunk that has no resulting line (i.e. all lines are prefixed with '-') if it has not otherwise been known if the patch deletes the file. Similarly, no old line means the file is being created. And we declare an error condition when the file created by a creation patch already exists, and/or when a deletion patch still leaves content in the file. These sanity checks are good safety measures, but breaks down when people feed a diff generated with --unified=0. This was recently noticed first by Matthew Wilcox and Gerrit Pape. This adds a new flag, --unified-zero, to allow bypassing these checks. If you are in control of the patch generation process, you should not use --unified=0 patch and fix it up with this flag; rather you should try work with a patch with context. But if all you have to work with is a patch without context, this flag may come handy as the last resort. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago