Граф коммитов

14 Коммитов

Автор SHA1 Сообщение Дата
Junio C Hamano ead51a75d5 Merge branch 'jc/apply-ws-prefix'
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-09-09 12:53:58 -07:00
Junio C Hamano d487b0ba50 apply: use the right attribute for paths in non-Git patches
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-08-07 12:17:07 -07:00
Elia Pinto 6003eb13c6 t4119-apply-config.sh: use the $( ... ) construct for command substitution
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>
2014-04-30 11:08:09 -07:00
Jonathan Nieder a48fcd8369 tests: add missing &&
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>
2010-11-09 11:59:49 -08:00
Jeff King 74f16b0c6f 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 11:39:16 -07:00
Junio C Hamano 29cc0ef1ab t4119: correct overeager war-on-whitespace
Earlier a6080a0a44 (War on whitespace)
dropped a necessary trailing whitespace from the test vector.
2007-11-24 16:46:42 -08:00
Junio C Hamano 5be60078c9 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-02 22:52:14 -07:00
Junio C Hamano a6080a0a44 War on whitespace
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-06-07 00:04:01 -07:00
Junio C Hamano fe6e0eecb0 t4119: test autocomputing -p<n> for traditional diff input.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-21 16:18:45 -08:00
Junio C Hamano 3e8a5db966 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-21 16:05:56 -08:00
Junio C Hamano 9987d7c58a 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 14:42:15 -08:00
Junio C Hamano c24e9757e9 t4119: add test for traditional patch and different p_value
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-21 01:14:22 -08:00
Junio C Hamano 56185f49d0 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-19 18:44:59 -08:00
Junio C Hamano dc7b24364d 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 13:13:32 -08:00