summaryrefslogtreecommitdiff
path: root/git-pull.sh
diff options
context:
space:
mode:
authorJunio C Hamano <junkio@cox.net>2006-09-17 08:04:24 (GMT)
committerJunio C Hamano <junkio@cox.net>2006-09-17 08:12:37 (GMT)
commit4be609625e48e908f2b76d35bfeb61a8ba3a83a0 (patch)
treeb3c78486a4aad76f56a6eebdef8a1113ab546c2a /git-pull.sh
parent8aac4b45f39a7c845848a75ac971717a1933d99f (diff)
downloadgit-4be609625e48e908f2b76d35bfeb61a8ba3a83a0.zip
git-4be609625e48e908f2b76d35bfeb61a8ba3a83a0.tar.gz
git-4be609625e48e908f2b76d35bfeb61a8ba3a83a0.tar.bz2
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>
Diffstat (limited to 'git-pull.sh')
0 files changed, 0 insertions, 0 deletions