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

10 Коммитов

Автор SHA1 Сообщение Дата
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