summaryrefslogtreecommitdiff
path: root/git-repack.sh
diff options
context:
space:
mode:
authorJunio C Hamano <junkio@cox.net>2007-02-21 22:31:10 (GMT)
committerJunio C Hamano <junkio@cox.net>2007-02-21 22:42:15 (GMT)
commit9987d7c58a847ab1605ae3216ff1ca95b19f0ad1 (patch)
treeb3ee784213e862551771c30ee3fa092ef6ee22d5 /git-repack.sh
parent6c912f5b04e3216a5487e03235a8454b754a464e (diff)
downloadgit-9987d7c58a847ab1605ae3216ff1ca95b19f0ad1.zip
git-9987d7c58a847ab1605ae3216ff1ca95b19f0ad1.tar.gz
git-9987d7c58a847ab1605ae3216ff1ca95b19f0ad1.tar.bz2
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>
Diffstat (limited to 'git-repack.sh')
0 files changed, 0 insertions, 0 deletions