mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-09 02:33:11 +01:00
Code Activity
git/t/t4119-apply-config.sh

163 lines
3 KiB
Bash
Raw Normal View History

Teach 'git apply' to look at $GIT_DIR/config When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17 22:12:52 +01:00
#!/bin/sh
#
# Copyright (c) 2007 Junio C Hamano
#
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>
2007-07-03 07:52:14 +02:00
test_description='git apply --whitespace=strip and configuration file.
Teach 'git apply' to look at $GIT_DIR/config When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17 22:12:52 +01:00
'
. ./test-lib.sh
test_expect_success setup '
git-apply: require -p<n> when working in a subdirectory. git-apply running inside a subdirectory, with or without --index, used to always assume that the patch is formatted in such a way to apply with -p1 from the toplevel, but it is more useful and consistent with the use of "GNU patch -p1" if it defaulted to assume that its input is meant to apply at the level it is invoked in. This changes the behaviour. It used to be that the patch generated this way would apply without any trick: edit Documentation/Makefile git diff >patch.file cd Documentation git apply ../patch.file You need to give an explicit -p2 to git-apply now. On the other hand, if you got a patch from somebody else who did not follow "patch is to apply from the top with -p1" convention, the input patch would start with: diff -u Makefile.old Makefile --- Makefile.old +++ Makefile and in such a case, you can apply it with: git apply -p0 patch.file Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20 02:57:29 +01:00
mkdir sub &&
echo A >sub/file1 &&
cp sub/file1 saved &&
git add sub/file1 &&
echo "B " >sub/file1 &&
Teach 'git apply' to look at $GIT_DIR/config When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17 22:12:52 +01:00
git diff >patch.file
'
t4119: add test for traditional patch and different p_value Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-21 10:14:22 +01:00
# Also handcraft GNU diff output; note this has trailing whitespace.
mask necessary whitespace policy violations in test scripts All of these violations are necessary parts of the tests (which are generally checking the behavior of trailing whitespace, or contain diff fragments with empty lines). Our solution is two-fold: 1. Process input with whitespace problems using tr. This has the added bonus that it becomes very obvious where the bogus whitespace is intended to go. 2. Move large diff fragments into their own supplemental files. This gets rid of the whitespace problem, since supplemental files are not checked, and it also makes the test script a bit easier to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-14 09:26:37 +02:00
tr '_' ' ' >gpatch.file <<\EOF &&
t4119: add test for traditional patch and different p_value Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-21 10:14:22 +01:00
--- file1 2007-02-21 01:04:24.000000000 -0800
+++ file1+ 2007-02-21 01:07:44.000000000 -0800
@@ -1 +1 @@
-A
mask necessary whitespace policy violations in test scripts All of these violations are necessary parts of the tests (which are generally checking the behavior of trailing whitespace, or contain diff fragments with empty lines). Our solution is two-fold: 1. Process input with whitespace problems using tr. This has the added bonus that it becomes very obvious where the bogus whitespace is intended to go. 2. Move large diff fragments into their own supplemental files. This gets rid of the whitespace problem, since supplemental files are not checked, and it also makes the test script a bit easier to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-14 09:26:37 +02:00
+B_
t4119: add test for traditional patch and different p_value Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-21 10:14:22 +01:00
EOF
git-apply: guess correct -p<n> value for non-git patches. This enhances the third point in the previous commit. When applying a non-git patch that begins like this: --- 2.6.orig/mm/slab.c +++ 2.6/mm/slab.c @@ -N,M +L,K @@@ ... and if you are in 'mm' subdirectory, we notice that -p2 is the right option to use to apply the patch in file slab.c in the current directory (i.e. mm/slab.c) The guess function also knows about this pattern, where you would need to use -p0 if applying from the top-level: --- mm/slab.c +++ mm/slab.c @@ -N,M +L,K @@@ ... Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:05:56 +01:00
sed -e 's|file1|sub/&|' gpatch.file >gpatch-sub.file &&
sed -e '
/^--- /s|file1|a/sub/&|
/^+++ /s|file1|b/sub/&|
' gpatch.file >gpatch-ab-sub.file &&
t4119: test autocomputing -p<n> for traditional diff input. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:18:45 +01:00
check_result () {
if grep " " "$1"
Teach 'git apply' to look at $GIT_DIR/config When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17 22:12:52 +01:00
then
echo "Eh?"
false
t4119: test autocomputing -p<n> for traditional diff input. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:18:45 +01:00
elif grep B "$1"
t4119: add test for traditional patch and different p_value Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-21 10:14:22 +01:00
then
Teach 'git apply' to look at $GIT_DIR/config When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17 22:12:52 +01:00
echo Happy
t4119: add test for traditional patch and different p_value Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-21 10:14:22 +01:00
else
echo "Huh?"
false
Teach 'git apply' to look at $GIT_DIR/config When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17 22:12:52 +01:00
fi
t4119: test autocomputing -p<n> for traditional diff input. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:18:45 +01:00
}
test_expect_success 'apply --whitespace=strip' '
rm -f sub/file1 &&
cp saved sub/file1 &&
git update-index --refresh &&
git apply --whitespace=strip patch.file &&
check_result sub/file1
Teach 'git apply' to look at $GIT_DIR/config When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17 22:12:52 +01:00
'
test_expect_success 'apply --whitespace=strip from config' '
git-apply: require -p<n> when working in a subdirectory. git-apply running inside a subdirectory, with or without --index, used to always assume that the patch is formatted in such a way to apply with -p1 from the toplevel, but it is more useful and consistent with the use of "GNU patch -p1" if it defaulted to assume that its input is meant to apply at the level it is invoked in. This changes the behaviour. It used to be that the patch generated this way would apply without any trick: edit Documentation/Makefile git diff >patch.file cd Documentation git apply ../patch.file You need to give an explicit -p2 to git-apply now. On the other hand, if you got a patch from somebody else who did not follow "patch is to apply from the top with -p1" convention, the input patch would start with: diff -u Makefile.old Makefile --- Makefile.old +++ Makefile and in such a case, you can apply it with: git apply -p0 patch.file Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20 02:57:29 +01:00
rm -f sub/file1 &&
cp saved sub/file1 &&
Teach 'git apply' to look at $GIT_DIR/config When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17 22:12:52 +01:00
git update-index --refresh &&
git config apply.whitespace strip &&
git apply patch.file &&
t4119: test autocomputing -p<n> for traditional diff input. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:18:45 +01:00
check_result sub/file1
Teach 'git apply' to look at $GIT_DIR/config When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17 22:12:52 +01:00
'
D=`pwd`
test_expect_success 'apply --whitespace=strip in subdir' '
cd "$D" &&
git config --unset-all apply.whitespace
git-apply: require -p<n> when working in a subdirectory. git-apply running inside a subdirectory, with or without --index, used to always assume that the patch is formatted in such a way to apply with -p1 from the toplevel, but it is more useful and consistent with the use of "GNU patch -p1" if it defaulted to assume that its input is meant to apply at the level it is invoked in. This changes the behaviour. It used to be that the patch generated this way would apply without any trick: edit Documentation/Makefile git diff >patch.file cd Documentation git apply ../patch.file You need to give an explicit -p2 to git-apply now. On the other hand, if you got a patch from somebody else who did not follow "patch is to apply from the top with -p1" convention, the input patch would start with: diff -u Makefile.old Makefile --- Makefile.old +++ Makefile and in such a case, you can apply it with: git apply -p0 patch.file Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20 02:57:29 +01:00
rm -f sub/file1 &&
cp saved sub/file1 &&
Teach 'git apply' to look at $GIT_DIR/config When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17 22:12:52 +01:00
git update-index --refresh &&
cd sub &&
git-apply: notice "diff --git" patch again Earlier one that tried to be too consistent with GNU patch by not stripping the leading path when we _know_ we are in a subdirectory and the patch is relative to the toplevel was a mistake. This fixes it. - No change to behaviour when it is run from the toplevel of the repository. - When run from a subdirectory to apply a git-generated patch, it uses the right -p<n> value automatically, with or without --index nor --cached option. - When run from a subdirectory to apply a randomly generated patch, it wants the right -p<n> value to be given by the user. The second one is a pure improvement to correct inconsistency between --index and non --index case, compared with 1.5.0. The third point could be further improved to guess what the right value for -p<n> should be by looking at the patch, but should be a topic of a separate patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-21 23:31:10 +01:00
git apply --whitespace=strip ../patch.file &&
t4119: test autocomputing -p<n> for traditional diff input. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:18:45 +01:00
check_result file1
Teach 'git apply' to look at $GIT_DIR/config When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17 22:12:52 +01:00
'
test_expect_success 'apply --whitespace=strip from config in subdir' '
cd "$D" &&
git config apply.whitespace strip &&
git-apply: require -p<n> when working in a subdirectory. git-apply running inside a subdirectory, with or without --index, used to always assume that the patch is formatted in such a way to apply with -p1 from the toplevel, but it is more useful and consistent with the use of "GNU patch -p1" if it defaulted to assume that its input is meant to apply at the level it is invoked in. This changes the behaviour. It used to be that the patch generated this way would apply without any trick: edit Documentation/Makefile git diff >patch.file cd Documentation git apply ../patch.file You need to give an explicit -p2 to git-apply now. On the other hand, if you got a patch from somebody else who did not follow "patch is to apply from the top with -p1" convention, the input patch would start with: diff -u Makefile.old Makefile --- Makefile.old +++ Makefile and in such a case, you can apply it with: git apply -p0 patch.file Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20 02:57:29 +01:00
rm -f sub/file1 &&
cp saved sub/file1 &&
Teach 'git apply' to look at $GIT_DIR/config When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17 22:12:52 +01:00
git update-index --refresh &&
cd sub &&
git-apply: notice "diff --git" patch again Earlier one that tried to be too consistent with GNU patch by not stripping the leading path when we _know_ we are in a subdirectory and the patch is relative to the toplevel was a mistake. This fixes it. - No change to behaviour when it is run from the toplevel of the repository. - When run from a subdirectory to apply a git-generated patch, it uses the right -p<n> value automatically, with or without --index nor --cached option. - When run from a subdirectory to apply a randomly generated patch, it wants the right -p<n> value to be given by the user. The second one is a pure improvement to correct inconsistency between --index and non --index case, compared with 1.5.0. The third point could be further improved to guess what the right value for -p<n> should be by looking at the patch, but should be a topic of a separate patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-21 23:31:10 +01:00
git apply ../patch.file &&
t4119: test autocomputing -p<n> for traditional diff input. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:18:45 +01:00
check_result file1
t4119: add test for traditional patch and different p_value Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-21 10:14:22 +01:00
'
test_expect_success 'same in subdir but with traditional patch input' '
cd "$D" &&
git config apply.whitespace strip &&
rm -f sub/file1 &&
cp saved sub/file1 &&
git update-index --refresh &&
cd sub &&
git-apply: guess correct -p<n> value for non-git patches. This enhances the third point in the previous commit. When applying a non-git patch that begins like this: --- 2.6.orig/mm/slab.c +++ 2.6/mm/slab.c @@ -N,M +L,K @@@ ... and if you are in 'mm' subdirectory, we notice that -p2 is the right option to use to apply the patch in file slab.c in the current directory (i.e. mm/slab.c) The guess function also knows about this pattern, where you would need to use -p0 if applying from the top-level: --- mm/slab.c +++ mm/slab.c @@ -N,M +L,K @@@ ... Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:05:56 +01:00
git apply ../gpatch.file &&
t4119: test autocomputing -p<n> for traditional diff input. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:18:45 +01:00
check_result file1
git-apply: guess correct -p<n> value for non-git patches. This enhances the third point in the previous commit. When applying a non-git patch that begins like this: --- 2.6.orig/mm/slab.c +++ 2.6/mm/slab.c @@ -N,M +L,K @@@ ... and if you are in 'mm' subdirectory, we notice that -p2 is the right option to use to apply the patch in file slab.c in the current directory (i.e. mm/slab.c) The guess function also knows about this pattern, where you would need to use -p0 if applying from the top-level: --- mm/slab.c +++ mm/slab.c @@ -N,M +L,K @@@ ... Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:05:56 +01:00
'
test_expect_success 'same but with traditional patch input of depth 1' '
cd "$D" &&
git config apply.whitespace strip &&
rm -f sub/file1 &&
cp saved sub/file1 &&
git update-index --refresh &&
cd sub &&
git apply ../gpatch-sub.file &&
t4119: test autocomputing -p<n> for traditional diff input. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:18:45 +01:00
check_result file1
git-apply: guess correct -p<n> value for non-git patches. This enhances the third point in the previous commit. When applying a non-git patch that begins like this: --- 2.6.orig/mm/slab.c +++ 2.6/mm/slab.c @@ -N,M +L,K @@@ ... and if you are in 'mm' subdirectory, we notice that -p2 is the right option to use to apply the patch in file slab.c in the current directory (i.e. mm/slab.c) The guess function also knows about this pattern, where you would need to use -p0 if applying from the top-level: --- mm/slab.c +++ mm/slab.c @@ -N,M +L,K @@@ ... Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:05:56 +01:00
'
test_expect_success 'same but with traditional patch input of depth 2' '
cd "$D" &&
git config apply.whitespace strip &&
rm -f sub/file1 &&
cp saved sub/file1 &&
git update-index --refresh &&
cd sub &&
git apply ../gpatch-ab-sub.file &&
t4119: test autocomputing -p<n> for traditional diff input. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:18:45 +01:00
check_result file1
'
test_expect_success 'same but with traditional patch input of depth 1' '
cd "$D" &&
git config apply.whitespace strip &&
rm -f sub/file1 &&
cp saved sub/file1 &&
git update-index --refresh &&
git apply -p0 gpatch-sub.file &&
check_result sub/file1
'
test_expect_success 'same but with traditional patch input of depth 2' '
cd "$D" &&
git config apply.whitespace strip &&
rm -f sub/file1 &&
cp saved sub/file1 &&
git update-index --refresh &&
git apply gpatch-ab-sub.file &&
check_result sub/file1
Teach 'git apply' to look at $GIT_DIR/config When neither --index nor --cached was used, git-apply did not try calling setup_git_directory(), which means it did not look at configuration files at all. This fixes it to call the setup function but still allow the command to be run in a directory not controlled by git. The bug probably meant that 'git apply', not moving up to the toplevel, did not apply properly formatted diffs from the toplevel when you are inside a subdirectory, even though 'git apply --index' would. As a side effect, this patch fixes it as well. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-17 22:12:52 +01:00
'
test_done
Copy permalink