Fix "git apply" to correctly enforce "match at the beginning"
authorJunio C Hamano <gitster@pobox.com>
Mon, 7 Apr 2008 02:21:45 +0000 (19:21 -0700)
committerJunio C Hamano <gitster@pobox.com>
Mon, 7 Apr 2008 02:21:45 +0000 (19:21 -0700)
commitee5a317e0130ab2db59db97c644576335530512d
tree840d35f9f8b587a0d9dc12df15205fcd1265bafc
parentf8dd64fdbf47ac65c1b8d2ed25b789ae2655f8c8
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>
builtin-apply.c
t/t4104-apply-boundary.sh