Code

apply --unidiff-zero: loosen sanity checks for --unidiff=0 patches
authorJunio C Hamano <junkio@cox.net>
Sun, 17 Sep 2006 08:04:24 +0000 (01:04 -0700)
committerJunio C Hamano <junkio@cox.net>
Sun, 17 Sep 2006 08:12:37 +0000 (01:12 -0700)
commit4be609625e48e908f2b76d35bfeb61a8ba3a83a0
treeb3c78486a4aad76f56a6eebdef8a1113ab546c2a
parent8aac4b45f39a7c845848a75ac971717a1933d99f
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>
builtin-apply.c
t/t3403-rebase-skip.sh
t/t4104-apply-boundary.sh [new file with mode: 0755]