kernel/git - git - PowerEL Git System

Tree: 7e8c8255e9

Author	SHA1	Message	Date
Junio C Hamano	fe6e0eecb0	t4119: test autocomputing -p<n> for traditional diff input. Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
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>	18 years ago
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>	18 years ago
Junio C Hamano	c24e9757e9	t4119: add test for traditional patch and different p_value Signed-off-by: Junio C Hamano <junkio@cox.net>	18 years ago
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>	18 years ago
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>	18 years ago