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>
2006-09-17 10:04:24 +02:00
|
|
|
#!/bin/sh
|
|
|
|
#
|
|
|
|
# Copyright (c) 2005 Junio C Hamano
|
|
|
|
#
|
|
|
|
|
2007-07-03 07:52:14 +02:00
|
|
|
test_description='git apply boundary tests
|
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>
2006-09-17 10:04:24 +02:00
|
|
|
|
|
|
|
'
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
L="c d e f g h i j k l m n o p q r s t u v w x"
|
|
|
|
|
|
|
|
test_expect_success setup '
|
|
|
|
for i in b '"$L"' y
|
|
|
|
do
|
|
|
|
echo $i
|
|
|
|
done >victim &&
|
|
|
|
cat victim >original &&
|
|
|
|
git update-index --add victim &&
|
|
|
|
|
|
|
|
: add to the head
|
|
|
|
for i in a b '"$L"' y
|
|
|
|
do
|
|
|
|
echo $i
|
|
|
|
done >victim &&
|
|
|
|
cat victim >add-a-expect &&
|
|
|
|
git diff victim >add-a-patch.with &&
|
|
|
|
git diff --unified=0 >add-a-patch.without &&
|
|
|
|
|
2008-08-30 22:20:31 +02:00
|
|
|
: insert at line two
|
|
|
|
for i in b a '"$L"' y
|
|
|
|
do
|
|
|
|
echo $i
|
|
|
|
done >victim &&
|
|
|
|
cat victim >insert-a-expect &&
|
|
|
|
git diff victim >insert-a-patch.with &&
|
|
|
|
git diff --unified=0 >insert-a-patch.without &&
|
|
|
|
|
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>
2006-09-17 10:04:24 +02:00
|
|
|
: modify at the head
|
|
|
|
for i in a '"$L"' y
|
|
|
|
do
|
|
|
|
echo $i
|
|
|
|
done >victim &&
|
|
|
|
cat victim >mod-a-expect &&
|
|
|
|
git diff victim >mod-a-patch.with &&
|
|
|
|
git diff --unified=0 >mod-a-patch.without &&
|
|
|
|
|
|
|
|
: remove from the head
|
|
|
|
for i in '"$L"' y
|
|
|
|
do
|
|
|
|
echo $i
|
|
|
|
done >victim &&
|
|
|
|
cat victim >del-a-expect &&
|
|
|
|
git diff victim >del-a-patch.with
|
|
|
|
git diff --unified=0 >del-a-patch.without &&
|
|
|
|
|
|
|
|
: add to the tail
|
|
|
|
for i in b '"$L"' y z
|
|
|
|
do
|
|
|
|
echo $i
|
|
|
|
done >victim &&
|
|
|
|
cat victim >add-z-expect &&
|
|
|
|
git diff victim >add-z-patch.with &&
|
|
|
|
git diff --unified=0 >add-z-patch.without &&
|
|
|
|
|
|
|
|
: modify at the tail
|
2008-08-30 22:20:31 +02:00
|
|
|
for i in b '"$L"' z
|
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>
2006-09-17 10:04:24 +02:00
|
|
|
do
|
|
|
|
echo $i
|
|
|
|
done >victim &&
|
|
|
|
cat victim >mod-z-expect &&
|
|
|
|
git diff victim >mod-z-patch.with &&
|
|
|
|
git diff --unified=0 >mod-z-patch.without &&
|
|
|
|
|
|
|
|
: remove from the tail
|
|
|
|
for i in b '"$L"'
|
|
|
|
do
|
|
|
|
echo $i
|
|
|
|
done >victim &&
|
|
|
|
cat victim >del-z-expect &&
|
|
|
|
git diff victim >del-z-patch.with
|
|
|
|
git diff --unified=0 >del-z-patch.without &&
|
|
|
|
|
|
|
|
: done
|
|
|
|
'
|
|
|
|
|
|
|
|
for with in with without
|
|
|
|
do
|
|
|
|
case "$with" in
|
|
|
|
with) u= ;;
|
|
|
|
without) u='--unidiff-zero ' ;;
|
|
|
|
esac
|
2008-08-30 22:20:31 +02:00
|
|
|
for kind in add-a add-z insert-a mod-a mod-z del-a del-z
|
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>
2006-09-17 10:04:24 +02:00
|
|
|
do
|
|
|
|
test_expect_success "apply $kind-patch $with context" '
|
|
|
|
cat original >victim &&
|
|
|
|
git update-index victim &&
|
|
|
|
git apply --index '"$u$kind-patch.$with"' || {
|
|
|
|
cat '"$kind-patch.$with"'
|
|
|
|
(exit 1)
|
|
|
|
} &&
|
2008-05-24 07:28:56 +02:00
|
|
|
test_cmp '"$kind"'-expect victim
|
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>
2006-09-17 10:04:24 +02:00
|
|
|
'
|
|
|
|
done
|
|
|
|
done
|
|
|
|
|
2008-08-30 22:20:31 +02:00
|
|
|
for kind in add-a add-z insert-a mod-a mod-z del-a del-z
|
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>
2006-09-17 10:04:24 +02:00
|
|
|
do
|
|
|
|
rm -f $kind-ng.without
|
|
|
|
sed -e "s/^diff --git /diff /" \
|
|
|
|
-e '/^index /d' \
|
|
|
|
<$kind-patch.without >$kind-ng.without
|
|
|
|
test_expect_success "apply non-git $kind-patch without context" '
|
|
|
|
cat original >victim &&
|
|
|
|
git update-index victim &&
|
|
|
|
git apply --unidiff-zero --index '"$kind-ng.without"' || {
|
|
|
|
cat '"$kind-ng.without"'
|
|
|
|
(exit 1)
|
|
|
|
} &&
|
2008-05-24 07:28:56 +02:00
|
|
|
test_cmp '"$kind"'-expect victim
|
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>
2006-09-17 10:04:24 +02:00
|
|
|
'
|
|
|
|
done
|
|
|
|
|
2008-04-07 04:21:45 +02:00
|
|
|
test_expect_success 'two lines' '
|
|
|
|
|
|
|
|
>file &&
|
|
|
|
git add file &&
|
|
|
|
echo aaa >file &&
|
|
|
|
git diff >patch &&
|
|
|
|
git add file &&
|
|
|
|
echo bbb >file &&
|
|
|
|
git add file &&
|
|
|
|
test_must_fail git apply --check patch
|
|
|
|
|
|
|
|
'
|
|
|
|
|
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>
2006-09-17 10:04:24 +02:00
|
|
|
test_done
|