summaryrefslogtreecommitdiff
path: root/sha1_name.c
diff options
context:
space:
mode:
authorJunio C Hamano <junkio@cox.net>2007-02-20 01:57:29 (GMT)
committerJunio C Hamano <junkio@cox.net>2007-02-20 02:44:59 (GMT)
commit56185f49d03cae28048146e902089ea366c6cd6c (patch)
tree93fccbc9ac5e8c80f731d2303c2522ea2fe6dd1a /sha1_name.c
parentaea1945744214bf84908586af8be1c098a6f346d (diff)
downloadgit-56185f49d03cae28048146e902089ea366c6cd6c.zip
git-56185f49d03cae28048146e902089ea366c6cd6c.tar.gz
git-56185f49d03cae28048146e902089ea366c6cd6c.tar.bz2
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>
Diffstat (limited to 'sha1_name.c')
0 files changed, 0 insertions, 0 deletions