summaryrefslogtreecommitdiff
path: root/t/t4119-apply-config.sh
AgeCommit message (Collapse)AuthorFilesLines
2010-11-09tests: add missing &&Libravatar Jonathan Nieder1-1/+1
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-14mask necessary whitespace policy violations in test scriptsLibravatar Jeff King1-2/+2
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>
2007-11-24t4119: correct overeager war-on-whitespaceLibravatar Junio C Hamano1-1/+1
Earlier a6080a0a44d5ead84db3dabbbc80e82df838533d (War on whitespace) dropped a necessary trailing whitespace from the test vector.
2007-07-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-1/+1
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+1
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-02-21t4119: test autocomputing -p<n> for traditional diff input.Libravatar Junio C Hamano1-74/+43
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-21git-apply: guess correct -p<n> value for non-git patches.Libravatar Junio C Hamano1-2/+54
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-21git-apply: notice "diff --git" patch againLibravatar Junio C Hamano1-2/+2
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-21t4119: add test for traditional patch and different p_valueLibravatar Junio C Hamano1-2/+49
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-19git-apply: require -p<n> when working in a subdirectory.Libravatar Junio C Hamano1-14/+18
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-17Teach 'git apply' to look at $GIT_DIR/configLibravatar Junio C Hamano1-0/+90
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>