summaryrefslogtreecommitdiff
path: root/t/t4119-apply-config.sh
AgeCommit message (Collapse)AuthorFilesLines
2014-09-09Merge branch 'jc/apply-ws-prefix'Libravatar Junio C Hamano1-0/+17
Applying a patch not generated by Git in a subdirectory used to check the whitespace breakage using the attributes for incorrect paths. Also whitespace checks were performed even for paths excluded via "git apply --exclude=<path>" mechanism. * jc/apply-ws-prefix: apply: omit ws check for excluded paths apply: hoist use_patch() helper for path exclusion up apply: use the right attribute for paths in non-Git patches
2014-08-07apply: use the right attribute for paths in non-Git patchesLibravatar Junio C Hamano1-0/+17
We parse each patchfile and find the name of the path the patch applies to, and then use that name to consult the attribute system to find the whitespace rules to be used, and also the target file (either in the working tree or in the index) to replay the changes against. Unlike a Git-generated patch, a non-Git patch is taken to have the pathnames relative to the current working directory. The names found in such a patch are modified by prepending the prefix by the prefix_patches() helper function introduced in 56185f49 (git-apply: require -p<n> when working in a subdirectory., 2007-02-19). However, this prefixing is done after the patch is fully parsed and affects only what target files are patched. Because the attributes are checked against the names found in the patch during the parsing, not against the final pathname, the whitespace check that is done during parsing ends up using attributes for a wrong path for non-Git patches. Fix this by doing the prefix much earlier, immediately after the header part of each patch is parsed and we learn the name of the path the patch affects. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-30t4119-apply-config.sh: use the $( ... ) construct for command substitutionLibravatar Elia Pinto1-1/+1
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do sed -i 's@`\(.*\)`@$(\1)@g' ${_f} done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>