{"thread":{"id":"6861","subject":"[PATCH] Teach core.autocrlf to 'git apply'","startedAt":"2007-02-17T20:37:25Z","lastAt":"2007-02-22T00:24:22Z","messageCount":49,"participants":["Junio C Hamano","Jeff King","Johannes Schindelin","Jakub Narebski","Linus Torvalds","Shawn O. Pearce","Simon 'corecode' Schubert","Daniel Barkalow"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"34892","messageId":"7vlkiwsepm.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":null,"subject":"[PATCH] Teach core.autocrlf to 'git apply'","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-17T20:37:25Z","receivedAt":"2007-02-17T20:37:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This teaches git-apply that the data read from and written to\nthe filesystem might need to get converted to adjust for local\nline-ending convention.\n\nSigned-off-by: Junio C Hamano \n---\n\n * Comes on top of lt/crlf branch which is part of 'next'.\n\n One problem that hasn't been solved is that git-apply without\n --index nor --cached does not read the configuration even\n when in a git-controlled working tree. This is not a new\n issue and needs to be addressed separately. For now, just to\n make testing easier, I tentatively added GIT_AUTOCRLF\n environment variable as a hack, but it should be removed from\n the real version.\n\n builtin-apply.c | 37 +++++++++++++++++++++++++++++++------\n t/t0020-crlf.sh | 22 +++++++++++++++++-----\n 2 files changed, 48 insertions(+), 11 deletions(-)\n\ndiff --git a/builtin-apply.c b/builtin-apply.c\nindex 3fefdac..18f7307 100644\n--- a/builtin-apply.c\n+++ b/builtin-apply.c\n@@ -1393,28 +1393,39 @@ static void show_stats(struct patch *patch)\n \tfree(qname);\n }\n \n-static int read_old_data(struct stat *st, const char *path, void *buf, unsigned long size)\n+static int read_old_data(struct stat *st, const char *path, char **buf_p, unsigned long *alloc_p, unsigned long *size_p)\n {\n \tint fd;\n \tunsigned long got;\n+\tunsigned long nsize;\n+\tchar *nbuf;\n+\tunsigned long size = *size_p;\n+\tchar *buf = *buf_p;\n \n \tswitch (st->st_mode & S_IFMT) {\n \tcase S_IFLNK:\n-\t\treturn readlink(path, buf, size);\n+\t\treturn readlink(path, buf, size) != size;\n \tcase S_IFREG:\n \t\tfd = open(path, O_RDONLY);\n \t\tif (fd < 0)\n \t\t\treturn error(\"unable to open %s\", path);\n \t\tgot = 0;\n \t\tfor (;;) {\n-\t\t\tint ret = xread(fd, (char *) buf + got, size - got);\n+\t\t\tint ret = xread(fd, buf + got, size - got);\n \t\t\tif (ret <= 0)\n \t\t\t\tbreak;\n \t\t\tgot += ret;\n \t\t}\n \t\tclose(fd);\n-\t\treturn got;\n-\n+\t\tnsize = got;\n+\t\tnbuf = buf;\n+\t\tif (convert_to_git(path, &nbuf, &nsize)) {\n+\t\t\tfree(buf);\n+\t\t\t*buf_p = nbuf;\n+\t\t\t*alloc_p = nsize;\n+\t\t\t*size_p = nsize;\n+\t\t}\n+\t\treturn got != size;\n \tdefault:\n \t\treturn -1;\n \t}\n@@ -1910,7 +1921,7 @@ static int apply_data(struct patch *patch, struct stat *st, struct cache_entry *\n \t\tsize = st->st_size;\n \t\talloc = size + 8192;\n \t\tbuf = xmalloc(alloc);\n-\t\tif (read_old_data(st, patch->old_name, buf, alloc) != size)\n+\t\tif (read_old_data(st, patch->old_name, &buf, &alloc, &size))\n \t\t\treturn error(\"read of %s failed\", patch->old_name);\n \t}\n \n@@ -2282,12 +2293,22 @@ static void add_index_file(const char *path, unsigned mode, void *buf, unsigned\n static int try_create_file(const char *path, unsigned int mode, const char *buf, unsigned long size)\n {\n \tint fd;\n+\tchar *nbuf;\n+\tunsigned long nsize;\n \n \tif (S_ISLNK(mode))\n \t\t/* Although buf:size is counted string, it also is NUL\n \t\t * terminated.\n \t\t */\n \t\treturn symlink(buf, path);\n+\tnsize = size;\n+\tnbuf = (char *) buf;\n+\tif (convert_to_working_tree(path, &nbuf, &nsize)) {\n+\t\tfree((char *) buf);\n+\t\tbuf = nbuf;\n+\t\tsize = nsize;\n+\t}\n+\n \tfd = open(path, O_CREAT | O_EXCL | O_WRONLY, (mode & 0100) ? 0777 : 0666);\n \tif (fd < 0)\n \t\treturn -1;\n@@ -2598,6 +2619,10 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)\n \n \tconst char *whitespace_option = NULL;\n \n+\t/* This still is undesirable... */\n+\tif (getenv(\"GIT_AUTOCRLF\"))\n+\t\tgit_default_config(\"core.autocrlf\", getenv(\"GIT_AUTOCRLF\"));\n+\n \tfor (i = 1; i < argc; i++) {\n \t\tconst char *arg = argv[i];\n \t\tchar *end;\ndiff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh\nindex 58a4d86..c64d48c 100755\n--- a/t/t0020-crlf.sh\n+++ b/t/t0020-crlf.sh\n@@ -180,11 +180,9 @@ test_expect_success 'apply patch (autocrlf=true)' '\n \tgit repo-config core.autocrlf true &&\n \tgit read-tree --reset -u HEAD &&\n \n-\t# Sore thumb\n-\tremove_cr one >tmp && mv -f tmp one &&\n-\n-\tgit apply patch.file &&\n-\ttest \"$patched\" = \"`git hash-object --stdin \n\n---\n\n builtin-apply.c | 21 +++++++----\n t/t4119-apply-config.sh | 90 +++++++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 103 insertions(+), 8 deletions(-)\n\ndiff --git a/builtin-apply.c b/builtin-apply.c\nindex 3fefdac..fc1d673 100644\n--- a/builtin-apply.c\n+++ b/builtin-apply.c\n@@ -2595,9 +2595,18 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)\n \tint read_stdin = 1;\n \tint inaccurate_eof = 0;\n \tint errs = 0;\n+\tint is_not_gitdir = 0;\n \n \tconst char *whitespace_option = NULL;\n \n+\tprefix = setup_git_directory_gently(&is_not_gitdir);\n+\tprefix_length = prefix ? strlen(prefix) : 0;\n+\tif (!is_not_gitdir) {\n+\t\tgit_config(git_apply_config);\n+\t\tif (apply_default_whitespace)\n+\t\t\tparse_whitespace_option(apply_default_whitespace);\n+\t}\n+\n \tfor (i = 1; i < argc; i++) {\n \t\tconst char *arg = argv[i];\n \t\tchar *end;\n@@ -2648,10 +2657,14 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)\n \t\t\tcontinue;\n \t\t}\n \t\tif (!strcmp(arg, \"--index\")) {\n+\t\t\tif (is_not_gitdir)\n+\t\t\t\tdie(\"--index outside a repository\");\n \t\t\tcheck_index = 1;\n \t\t\tcontinue;\n \t\t}\n \t\tif (!strcmp(arg, \"--cached\")) {\n+\t\t\tif (is_not_gitdir)\n+\t\t\t\tdie(\"--cached outside a repository\");\n \t\t\tcheck_index = 1;\n \t\t\tcached = 1;\n \t\t\tcontinue;\n@@ -2700,14 +2713,6 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)\n \t\t\tinaccurate_eof = 1;\n \t\t\tcontinue;\n \t\t}\n-\n-\t\tif (check_index && prefix_length < 0) {\n-\t\t\tprefix = setup_git_directory();\n-\t\t\tprefix_length = prefix ? strlen(prefix) : 0;\n-\t\t\tgit_config(git_apply_config);\n-\t\t\tif (!whitespace_option && apply_default_whitespace)\n-\t\t\t\tparse_whitespace_option(apply_default_whitespace);\n-\t\t}\n \t\tif (0 < prefix_length)\n \t\t\targ = prefix_filename(prefix, prefix_length, arg);\n \ndiff --git a/t/t4119-apply-config.sh b/t/t4119-apply-config.sh\nnew file mode 100755\nindex 0000000..0e8ea7e\n--- /dev/null\n+++ b/t/t4119-apply-config.sh\n@@ -0,0 +1,90 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2007 Junio C Hamano\n+#\n+\n+test_description='git-apply --whitespace=strip and configuration file.\n+\n+'\n+\n+. ./test-lib.sh\n+\n+test_expect_success setup '\n+\techo A >file1 &&\n+\tcp file1 saved &&\n+\tgit add file1 &&\n+\techo \"B \" >file1 &&\n+\tgit diff >patch.file\n+'\n+\n+test_expect_success 'apply --whitespace=strip' '\n+\n+\tcp saved file1 &&\n+\tgit update-index --refresh &&\n+\n+\tgit apply --whitespace=strip patch.file &&\n+\tif grep \" \" file1\n+\tthen\n+\t\techo \"Eh?\"\n+\t\tfalse\n+\telse\n+\t\techo Happy\n+\tfi\n+'\n+\n+test_expect_success 'apply --whitespace=strip from config' '\n+\n+\tcp saved file1 &&\n+\tgit update-index --refresh &&\n+\n+\tgit config apply.whitespace strip &&\n+\tgit apply patch.file &&\n+\tif grep \" \" file1\n+\tthen\n+\t\techo \"Eh?\"\n+\t\tfalse\n+\telse\n+\t\techo Happy\n+\tfi\n+'\n+\n+mkdir sub\n+D=`pwd`\n+\n+test_expect_success 'apply --whitespace=strip in subdir' '\n+\n+\tcd \"$D\" &&\n+\tgit config --unset-all apply.whitespace\n+\tcp saved file1 &&\n+\tgit update-index --refresh &&\n+\n+\tcd sub &&\n+\tgit apply --whitespace=strip ../patch.file &&\n+\tif grep \" \" ../file1\n+\tthen\n+\t\techo \"Eh?\"\n+\t\tfalse\n+\telse\n+\t\techo Happy\n+\tfi\n+'\n+\n+test_expect_success 'apply --whitespace=strip from config in subdir' '\n+\n+\tcd \"$D\" &&\n+\tgit config apply.whitespace strip &&\n+\tcp saved file1 &&\n+\tgit update-index --refresh &&\n+\n+\tcd sub &&\n+\tgit apply ../patch.file &&\n+\tif grep \" \" file1\n+\tthen\n+\t\techo \"Eh?\"\n+\t\tfalse\n+\telse\n+\t\techo Happy\n+\tfi\n+'\n+\n+test_done\n"},{"id":"34903","messageId":"20070217232603.GB30839@coredump.intra.peff.net","threadId":"6861","inReplyTo":"7v8xewsd2j.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-17T23:26:03Z","receivedAt":"2007-02-17T23:26:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Feb 17, 2007 at 01:12:52PM -0800, Junio C Hamano wrote:\n\n> +\tprefix = setup_git_directory_gently(&is_not_gitdir);\n> +\tprefix_length = prefix ? strlen(prefix) : 0;\n> +\tif (!is_not_gitdir) {\n> +\t\tgit_config(git_apply_config);\n> +\t\tif (apply_default_whitespace)\n> +\t\t\tparse_whitespace_option(apply_default_whitespace);\n> +\t}\n> +\n\nIf I read this correctly, running 'git apply' inside a git repository\nwill parse $GIT_DIR/config and $HOME/.gitconfig. However, outside of a\nrepository it will parse neither. It would make more sense to me to\nstill parse $HOME/.gitconfig to pick up the user's global options.\n\n-Peff\n"},{"id":"34905","messageId":"7vmz3cqs3d.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"20070217232603.GB30839@coredump.intra.peff.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-17T23:31:18Z","receivedAt":"2007-02-17T23:31:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Sat, Feb 17, 2007 at 01:12:52PM -0800, Junio C Hamano wrote:\n>\n>> +\tprefix = setup_git_directory_gently(&is_not_gitdir);\n>> +\tprefix_length = prefix ? strlen(prefix) : 0;\n>> +\tif (!is_not_gitdir) {\n>> +\t\tgit_config(git_apply_config);\n>> +\t\tif (apply_default_whitespace)\n>> +\t\t\tparse_whitespace_option(apply_default_whitespace);\n>> +\t}\n>> +\n>\n> If I read this correctly, running 'git apply' inside a git repository\n> will parse $GIT_DIR/config and $HOME/.gitconfig. However, outside of a\n> repository it will parse neither. It would make more sense to me to\n> still parse $HOME/.gitconfig to pick up the user's global options.\n\nI thought about that, but decided against it. If you are truly\noperating outside a git managed repository, it does not feel\nright to apply configuration user has for git.\n"},{"id":"34907","messageId":"20070217233203.GA6014@coredump.intra.peff.net","threadId":"6861","inReplyTo":"7vmz3cqs3d.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-17T23:32:04Z","receivedAt":"2007-02-17T23:32:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Feb 17, 2007 at 03:31:18PM -0800, Junio C Hamano wrote:\n\n> I thought about that, but decided against it. If you are truly\n> operating outside a git managed repository, it does not feel\n> right to apply configuration user has for git.\n\nThen why are they using git-apply, and not patch?\n\n-Peff\n"},{"id":"34914","messageId":"Pine.LNX.4.63.0702180105000.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6861","inReplyTo":"20070217232603.GB30839@coredump.intra.peff.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-18T00:06:41Z","receivedAt":"2007-02-18T00:06:41Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 17 Feb 2007, Jeff King wrote:\n\n> On Sat, Feb 17, 2007 at 01:12:52PM -0800, Junio C Hamano wrote:\n> \n> > +\tprefix = setup_git_directory_gently(&is_not_gitdir);\n> > +\tprefix_length = prefix ? strlen(prefix) : 0;\n> > +\tif (!is_not_gitdir) {\n> > +\t\tgit_config(git_apply_config);\n> > +\t\tif (apply_default_whitespace)\n> > +\t\t\tparse_whitespace_option(apply_default_whitespace);\n> > +\t}\n> > +\n> \n> If I read this correctly, running 'git apply' inside a git repository\n> will parse $GIT_DIR/config and $HOME/.gitconfig. However, outside of a\n> repository it will parse neither. It would make more sense to me to\n> still parse $HOME/.gitconfig to pick up the user's global options.\n\nIn git-config we solve the problem by running git_config regardless of \nis_not_gitdir. However, I suspect you have to 'cd' back to prefix, or else \nthe patch gets applied in the repo root, right? (Disclaimer: I did not \nread the patch.)\n\nCiao,\nDscho\n"},{"id":"34915","messageId":"Pine.LNX.4.63.0702180107250.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6861","inReplyTo":"7vmz3cqs3d.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-18T00:08:03Z","receivedAt":"2007-02-18T00:08:03Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 17 Feb 2007, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > On Sat, Feb 17, 2007 at 01:12:52PM -0800, Junio C Hamano wrote:\n> >\n> >> +\tprefix = setup_git_directory_gently(&is_not_gitdir);\n> >> +\tprefix_length = prefix ? strlen(prefix) : 0;\n> >> +\tif (!is_not_gitdir) {\n> >> +\t\tgit_config(git_apply_config);\n> >> +\t\tif (apply_default_whitespace)\n> >> +\t\t\tparse_whitespace_option(apply_default_whitespace);\n> >> +\t}\n> >> +\n> >\n> > If I read this correctly, running 'git apply' inside a git repository\n> > will parse $GIT_DIR/config and $HOME/.gitconfig. However, outside of a\n> > repository it will parse neither. It would make more sense to me to\n> > still parse $HOME/.gitconfig to pick up the user's global options.\n> \n> I thought about that, but decided against it. If you are truly\n> operating outside a git managed repository, it does not feel\n> right to apply configuration user has for git.\n\nThat is a good point. But in the same vein, why not have a flag to \ngit-apply, and let it ignore the configuration altogether?\n\nCiao,\nDscho\n"},{"id":"34918","messageId":"7vbqjsqpgs.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.63.0702180107250.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-18T00:28:03Z","receivedAt":"2007-02-18T00:28:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> > If I read this correctly, running 'git apply' inside a git repository\n>> > will parse $GIT_DIR/config and $HOME/.gitconfig. However, outside of a\n>> > repository it will parse neither. It would make more sense to me to\n>> > still parse $HOME/.gitconfig to pick up the user's global options.\n>> \n>> I thought about that, but decided against it. If you are truly\n>> operating outside a git managed repository, it does not feel\n>> right to apply configuration user has for git.\n>\n> That is a good point. But in the same vein, why not have a flag to \n> git-apply, and let it ignore the configuration altogether?\n\nDo you mean --whitespace=strip option from the command line?\n\nBut I think Jeff is right. It would make sense to let apply\nand perhaps 'diff', if we can somehow merge 'diff2' into it,\nstill read from $HOME/.gitconfig if available.\n"},{"id":"34919","messageId":"7v64a0qpa8.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.63.0702180105000.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-18T00:31:59Z","receivedAt":"2007-02-18T00:31:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> ... However, I suspect you have to 'cd' back to prefix, or else \n> the patch gets applied in the repo root, right? (Disclaimer: I did not \n> read the patch.)\n\nActually, not cd-ing up was a bug, since git diff is always\nrelative to root. The behaviour to apply the same file was\ninconsistent between with --index and without as far as I can\ntell.\n"},{"id":"34920","messageId":"Pine.LNX.4.63.0702180135240.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6861","inReplyTo":"7vbqjsqpgs.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-18T00:40:51Z","receivedAt":"2007-02-18T00:40:51Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 17 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> > If I read this correctly, running 'git apply' inside a git repository\n> >> > will parse $GIT_DIR/config and $HOME/.gitconfig. However, outside of a\n> >> > repository it will parse neither. It would make more sense to me to\n> >> > still parse $HOME/.gitconfig to pick up the user's global options.\n> >> \n> >> I thought about that, but decided against it. If you are truly\n> >> operating outside a git managed repository, it does not feel\n> >> right to apply configuration user has for git.\n> >\n> > That is a good point. But in the same vein, why not have a flag to \n> > git-apply, and let it ignore the configuration altogether?\n> \n> Do you mean --whitespace=strip option from the command line?\n\nI meant something like \n\"--whitespace=I-know-the-patch-is-sane-but-lets-add-cr-to-all-lfs\".\n\n> But I think Jeff is right. It would make sense to let apply\n> and perhaps 'diff', if we can somehow merge 'diff2' into it,\n> still read from $HOME/.gitconfig if available.\n\nYes, especially if you are soo used to colours as I grew to be used to \nthem. This was literally one of the reasons I wrote diff2 in the first \nplace. Another was --color-words.\n\nBTW any good ideas how to make diff fall back to diff2, so that no similar \ncase falls back to diff-index?\n\nI am really wondering if you can have a syntax which Does The Right Thing \nat all times. Maybe we can teach diff that exactly two arguments, which \nboth exist in the filesystem, and at least one of them is not tracked, \nthen please use diff2? I wonder how often you do something like\n\n\tgit diff object.c object-refs.c\n\nand how confusing it would be that it could mean two things, diff2 _and_ \ndiff-index?\n\nCiao,\nDscho\n"},{"id":"34922","messageId":"Pine.LNX.4.63.0702180151060.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6861","inReplyTo":"7v64a0qpa8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-18T00:53:52Z","receivedAt":"2007-02-18T00:53:52Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 17 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > ... However, I suspect you have to 'cd' back to prefix, or else the \n> > patch gets applied in the repo root, right? (Disclaimer: I did not \n> > read the patch.)\n> \n> Actually, not cd-ing up was a bug, since git diff is always relative to \n> root. The behaviour to apply the same file was inconsistent between \n> with --index and without as far as I can tell.\n\nFor the same reason that I like git-merge-file, and git-diff2, namely to \nhave a _sane_ tool with a lot of options, which works the same everywhere \nI have git, I also like git-apply.\n\nAnd I use git-apply to apply patches way more often than \"patch\" these \ndays. And I _think_ that it is a feature that it does not cd-up before \ntrying to apply the stuff. In git.git, I cannot think of a reasonable use \ncase for applying something not relative-to-root, but I had that use case \nin some other (git-tracked) project.\n\nSo my vote is to leave the cwd where it is in git-apply.\n\nCiao,\nDscho\n"},{"id":"34923","messageId":"7vsld4p99g.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.63.0702180135240.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-18T01:03:23Z","receivedAt":"2007-02-18T01:03:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Sat, 17 Feb 2007, Junio C Hamano wrote:\n> ...\n>> But I think Jeff is right. It would make sense to let apply\n>> and perhaps 'diff', if we can somehow merge 'diff2' into it,\n>> still read from $HOME/.gitconfig if available.\n>\n> Yes, especially if you are soo used to colours as I grew to be used to \n> them. This was literally one of the reasons I wrote diff2 in the first \n> place. Another was --color-words.\n\nTrue. Paches welcome ;-).\n\n> BTW any good ideas how to make diff fall back to diff2, so that no similar \n> case falls back to diff-index?\n>\n> I am really wondering if you can have a syntax which Does The Right Thing \n> at all times. Maybe we can teach diff that exactly two arguments, which \n> both exist in the filesystem, and at least one of them is not tracked, \n> then please use diff2? I wonder how often you do something like\n>\n> \tgit diff object.c object-refs.c\n>\n> and how confusing it would be that it could mean two things, diff2 _and_ \n> diff-index?\n\nI _think_ the case I would want to use diff2 are:\n\n (1) I am totally outside a git repository.\n\nor\n\n (2) I am inside a git repository but I want to compare two\n specific managed files, say GIT-VERSION-GEN and\n git-gui/GIT-VERSION-GEN.\n\nNow, (1) can be had by moving the RUN_SETUP bit out of entry for\n\"diff\" in git.c, and do it only when we know we are in a repo\n(maybe using \"setup gently\"). If we are outside of a\nrepository, any of the existing diff-* brothers do not make much\nsense --- we can always do diff2.\n\nFor (2), I _think_ it may be useful sometimes but not very\noften, so how about a specific option that you require upfront?\n\n\tgit diff --fs --color-words GIT-VERSION-GEN git-gui/GIT-VERSION-GEN\n\nI can do almost that with\n\n\tgit diff --color-words :GIT-VERSION-GEN :git-gui/GIT-VERSION-GEN\n\nbut, it compares indexed ones, not from the working tree, so it\nis not exactly the same. However, the difference may not make\npractical difference in this particular example, though. When I\nwant to know the differences between two tracked files, it is\nusually becausel I want to see if there are similarities to be\nconsolidated, and I would do that before starting to alter\nworking tree files.\n\nAlso, strictly speaking, there is third one:\n\n (3) I am inside a git repository but I want to compare files\n that do not have anything to do with the project I am\n currently working on:\n\n\tgit diff --fs /etc/skel/profile $HOME/.profile\n\nwhile I do not think this usage makes any sense, an explicit\nflag upfront saves you from wondering what the user meant.\n"},{"id":"34925","messageId":"Pine.LNX.4.63.0702180210490.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6861","inReplyTo":"7vsld4p99g.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-18T01:15:06Z","receivedAt":"2007-02-18T01:15:06Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 17 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Sat, 17 Feb 2007, Junio C Hamano wrote:\n> > ...\n> >> But I think Jeff is right. It would make sense to let apply\n> >> and perhaps 'diff', if we can somehow merge 'diff2' into it,\n> >> still read from $HOME/.gitconfig if available.\n> >\n> > Yes, especially if you are soo used to colours as I grew to be used to \n> > them. This was literally one of the reasons I wrote diff2 in the first \n> > place. Another was --color-words.\n> \n> True. Paches welcome ;-).\n\nI sent it out already... It was titled \"[PATCH] Add `git diff2`, a GNU \ndiff workalike\" ;-)\n\n> > BTW any good ideas how to make diff fall back to diff2, so that no similar \n> > case falls back to diff-index?\n> >\n> > I am really wondering if you can have a syntax which Does The Right Thing \n> > at all times. Maybe we can teach diff that exactly two arguments, which \n> > both exist in the filesystem, and at least one of them is not tracked, \n> > then please use diff2? I wonder how often you do something like\n> >\n> > \tgit diff object.c object-refs.c\n> >\n> > and how confusing it would be that it could mean two things, diff2 _and_ \n> > diff-index?\n> \n> I _think_ the case I would want to use diff2 are:\n> \n> (1) I am totally outside a git repository.\n> \n> or\n> \n> (2) I am inside a git repository but I want to compare two\n> specific managed files, say GIT-VERSION-GEN and\n> git-gui/GIT-VERSION-GEN.\n> \n> Now, (1) can be had by moving the RUN_SETUP bit out of entry for\n> \"diff\" in git.c, and do it only when we know we are in a repo\n> (maybe using \"setup gently\"). If we are outside of a\n> repository, any of the existing diff-* brothers do not make much\n> sense --- we can always do diff2.\n> \n> For (2), I _think_ it may be useful sometimes but not very\n> often, so how about a specific option that you require upfront?\n> \n> \tgit diff --fs --color-words GIT-VERSION-GEN git-gui/GIT-VERSION-GEN\n> \n> I can do almost that with\n> \n> \tgit diff --color-words :GIT-VERSION-GEN :git-gui/GIT-VERSION-GEN\n> \n> but, it compares indexed ones, not from the working tree, so it\n> is not exactly the same. However, the difference may not make\n> practical difference in this particular example, though. When I\n> want to know the differences between two tracked files, it is\n> usually becausel I want to see if there are similarities to be\n> consolidated, and I would do that before starting to alter\n> working tree files.\n> \n> Also, strictly speaking, there is third one:\n> \n> (3) I am inside a git repository but I want to compare files\n> that do not have anything to do with the project I am\n> currently working on:\n> \n> \tgit diff --fs /etc/skel/profile $HOME/.profile\n> \n> while I do not think this usage makes any sense, an explicit\n> flag upfront saves you from wondering what the user meant.\n\nAnd there is always\n\n (4) I am inside a git repository and want to compare one tracked file \n with one non-tracked file, and\n (5) I am outside of a git repository, but want to compare one tracked \n file (by absolute path) with an arbitrary other file.\n\nThe longer I think about it, the more I am convinced that trying to \nintegrate diff2 into diff _will_ lead to errors due to my trained, but \ndisobeying, fingers.\n\nI also debated with myself calling it diff-two or diff-direct (both not \nreally convincing), or even diff-file (too similar to diff-files), but I \ncould not come up with a better name than diff2. Which is also very easy \nto write, I have to say.\n\nCiao,\nDscho\n"},{"id":"34927","messageId":"7vhctkp8gk.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.63.0702180151060.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-18T01:20:43Z","receivedAt":"2007-02-18T01:20:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> And I use git-apply to apply patches way more often than \"patch\" these \n> days. And I _think_ that it is a feature that it does not cd-up before \n> trying to apply the stuff. In git.git, I cannot think of a reasonable use \n> case for applying something not relative-to-root, but I had that use case \n> in some other (git-tracked) project.\n>\n> So my vote is to leave the cwd where it is in git-apply.\n\nI strongly disagree from my recent day-job experience. I was\nfeeding some changes to my co-worker's repository from my\nuncommitted changes (because it was incomplete but the part\nneeded to unstuck him was ready). The day job project is much\ndeeper than git.git, and the changes were to two files in a\ndirectory somewhat deep.\n\nSo I went there and said \"git apply --index P.diff\", which\napplied cleanly. But the other \"git apply --index Q.diff\"\ndidn't.\n\nSo naturally I said:\n\n\t$ git apply --reject Q.diff\n error: filfre/frotz/nitfol.c: No such file or directory\n\nI ended up editing filfre/frotz/ out of Q.diff in his editor.\nExplaining why P.diff and Q.diff, both of which were about the\nfiles in the same dirrectly, behaved differently was not pretty\nto git uninitiated.\n\nLeaving --index case and working-tree-only case inconsistent is\nbad. We really should fix it (I really wish I found it out\nbefore 1.5.0 went out).\n"},{"id":"34928","messageId":"Pine.LNX.4.63.0702180226480.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6861","inReplyTo":"7vhctkp8gk.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-18T01:29:17Z","receivedAt":"2007-02-18T01:29:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 17 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > And I use git-apply to apply patches way more often than \"patch\" these \n> > days. And I _think_ that it is a feature that it does not cd-up before \n> > trying to apply the stuff. In git.git, I cannot think of a reasonable use \n> > case for applying something not relative-to-root, but I had that use case \n> > in some other (git-tracked) project.\n> >\n> > So my vote is to leave the cwd where it is in git-apply.\n> \n> I strongly disagree from my recent day-job experience. [Explains a \n> convincing use case in favour of cd-up.]\n\nHmm. I have to think about that. But a consequence of what you suggest \nwould be to disallow git-apply outside of a repository, because then you \nwould introduce _another_ inconsistency (git-apply without --index would \nbehave differently when inside a repo than when outside of one).\n\nCiao,\nDscho\n"},{"id":"34930","messageId":"7v3b54p78r.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.63.0702180210490.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-18T01:47:00Z","receivedAt":"2007-02-18T01:47:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> Johannes Schindelin writes:\n>> \n>> > On Sat, 17 Feb 2007, Junio C Hamano wrote:\n>> > ...\n>> >> But I think Jeff is right. It would make sense to let apply\n>> >> and perhaps 'diff', if we can somehow merge 'diff2' into it,\n>> >> still read from $HOME/.gitconfig if available.\n>> >\n>> > Yes, especially if you are soo used to colours as I grew to be used to \n>> > them. This was literally one of the reasons I wrote diff2 in the first \n>> > place. Another was --color-words.\n>> \n>> True. Paches welcome ;-).\n>\n> I sent it out already... It was titled \"[PATCH] Add `git diff2`, a GNU \n> diff workalike\" ;-)\n\nI thought we were talking about making 'git apply' to read from\n$HOME/.gitconfig even outside a git repository.\n\nA funny thing is that I was suspecting that calling git_config()\nwould fail if you are not in a git repository after you called\nsetup_git_directory_gently() with no_git_ok). The lower level\ndoes return error because \".git/config\" does not exist, but it\ndoes not call error() to say why it failed. Callers typically\nignore the return value from the function, so it ends up\nworking.\n\nSo this simple patch is the welcomed one for now ;-)\n\n-- >8 --\n\ndiff --git a/builtin-apply.c b/builtin-apply.c\nindex 6ed257d..20fb5bd 100644\n--- a/builtin-apply.c\n+++ b/builtin-apply.c\n@@ -2622,11 +2622,9 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)\n \n \tprefix = setup_git_directory_gently(&is_not_gitdir);\n \tprefix_length = prefix ? strlen(prefix) : 0;\n-\tif (!is_not_gitdir) {\n-\t\tgit_config(git_apply_config);\n-\t\tif (apply_default_whitespace)\n-\t\t\tparse_whitespace_option(apply_default_whitespace);\n-\t}\n+\tgit_config(git_apply_config);\n+\tif (apply_default_whitespace)\n+\t\tparse_whitespace_option(apply_default_whitespace);\n \n \tfor (i = 1; i < argc; i++) {\n \t\tconst char *arg = argv[i];\n\n-- 8< --\n\n> The longer I think about it, the more I am convinced that trying to \n> integrate diff2 into diff _will_ lead to errors due to my trained, but \n> disobeying, fingers.\n>\n> I also debated with myself calling it diff-two or diff-direct (both not \n> really convincing), or even diff-file (too similar to diff-files), but I \n> could not come up with a better name than diff2. Which is also very easy \n> to write, I have to say.\n\nHmmmmmmmmmmmmmmmmmmmm.\n\nI do agree diff-file is too confusing with diff-files, but...\n\nIn any case, I am done for the evening, and your patch did not\napply to any of the well-known versions, so perhaps I can take a\nrest and have dinner and hope to find a respun one that\neverybody on the list agrees with its name in my mailbox later?\n;-)\n\nI've parked the --color --check one at near the tip of 'pu', but\nit appears its handling of whitespace warning is broken.\n\nFor example, from a patch that does this (I replaced a HT with =\nand SP with _):\n\n @@ -1,6 +1,6 @@\n # The default target of this Makefile is...\n all:\n -\n +_=ab_\n # Define NO_OPENSSL\n # This also implies\n #\n\nI get:\n\n Makefile:3: space before tab.white space at end: +=ab_\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~\n\nwhere ~ are colored in whitespace warning color.\n\n\t\n"},{"id":"34929","messageId":"er8b4s$o7n$1@sea.gmane.org","threadId":"6861","inReplyTo":"7vsld4p99g.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-18T01:48:02Z","receivedAt":"2007-02-18T01:48:02Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> I can do almost that with\n> \n>         git diff --color-words :GIT-VERSION-GEN :git-gui/GIT-VERSION-GEN\n> \n> but, it compares indexed ones, not from the working tree, so it\n> is not exactly the same.\n\nNot ::GIT-VERSION-GEN? \n\nWe could use :-1: for filesystem (working directory, :-: in short, version.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"34931","messageId":"7vy7mwnsm9.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.63.0702180226480.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-18T01:48:14Z","receivedAt":"2007-02-18T01:48:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> I strongly disagree from my recent day-job experience. [Explains a \n>> convincing use case in favour of cd-up.]\n>\n> Hmm. I have to think about that. But a consequence of what you suggest \n> would be to disallow git-apply outside of a repository, because then you \n> would introduce _another_ inconsistency (git-apply without --index would \n> behave differently when inside a repo than when outside of one).\n\nWhy? git-apply outside is like 'patch' isn't it?\n"},{"id":"34932","messageId":"Pine.LNX.4.63.0702180259340.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6861","inReplyTo":"7v3b54p78r.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-18T02:00:59Z","receivedAt":"2007-02-18T02:00:59Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 17 Feb 2007, Junio C Hamano wrote:\n\n> I do agree diff-file is too confusing with diff-files, but...\n\n... but nobody writes out diff-files these days, right?\n\n> In any case, I am done for the evening, and your patch did not apply to \n> any of the well-known versions, so perhaps I can take a rest and have \n> dinner and hope to find a respun one that everybody on the list agrees \n> with its name in my mailbox later? ;-)\n\n;-)\n\nWell, that'll have to wait a bit. I am way past bed-time. Same goes for \nthe colour --check thing. Will work on that tomorrow or Monday.\n\nCiao,\nDscho\n"},{"id":"34933","messageId":"Pine.LNX.4.63.0702180301220.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6861","inReplyTo":"7vy7mwnsm9.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-18T02:01:49Z","receivedAt":"2007-02-18T02:01:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 17 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> I strongly disagree from my recent day-job experience. [Explains a \n> >> convincing use case in favour of cd-up.]\n> >\n> > Hmm. I have to think about that. But a consequence of what you suggest \n> > would be to disallow git-apply outside of a repository, because then you \n> > would introduce _another_ inconsistency (git-apply without --index would \n> > behave differently when inside a repo than when outside of one).\n> \n> Why? git-apply outside is like 'patch' isn't it?\n\nSo, why shouldn't it be the same inside? That's the inconsistency I am \nalluding to.\n\nCiao,\nDscho\n"},{"id":"34934","messageId":"7vlkiwnrl7.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.63.0702180301220.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-18T02:10:28Z","receivedAt":"2007-02-18T02:10:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Sat, 17 Feb 2007, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> >> I strongly disagree from my recent day-job experience. [Explains a \n>> >> convincing use case in favour of cd-up.]\n>> >\n>> > Hmm. I have to think about that. But a consequence of what you suggest \n>> > would be to disallow git-apply outside of a repository, because then you \n>> > would introduce _another_ inconsistency (git-apply without --index would \n>> > behave differently when inside a repo than when outside of one).\n>> \n>> Why? git-apply outside is like 'patch' isn't it?\n>\n> So, why shouldn't it be the same inside? That's the inconsistency I am \n> alluding to.\n\nIt appears that you are saying we cannot make it consistent in\nboth ways, and you are probably right.\n\nI think git should cater first to git users who use git in git\nrepositories, which means consistency inside a git repository\nbetween with --index and without is more important.\n\nWe can certainly teach 'git apply' without --index/--cache a new\n\"stay where you are\" option to behave like patch (but do that\nonly without --index/--cache) inside a git repository for\nspecial cases.\n"},{"id":"34935","messageId":"7vejoonrdm.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.63.0702180259340.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-18T02:15:01Z","receivedAt":"2007-02-18T02:15:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Sat, 17 Feb 2007, Junio C Hamano wrote:\n>\n>> I do agree diff-file is too confusing with diff-files, but...\n>\n> ... but nobody writes out diff-files these days, right?\n\nActually, \"diff-files -c -p\" while looking at a merge conflict\nis the only thing I found \"git diff\" does not let me do. The\nlatter always gives condensed combined diff.\n"},{"id":"34952","messageId":"Pine.LNX.4.63.0702181240320.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6861","inReplyTo":"7vejoonrdm.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-18T11:40:58Z","receivedAt":"2007-02-18T11:40:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 17 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Sat, 17 Feb 2007, Junio C Hamano wrote:\n> >\n> >> I do agree diff-file is too confusing with diff-files, but...\n> >\n> > ... but nobody writes out diff-files these days, right?\n> \n> Actually, \"diff-files -c -p\" while looking at a merge conflict\n> is the only thing I found \"git diff\" does not let me do. The\n> latter always gives condensed combined diff.\n\nSo, diff2 is my preference. If anybody has better suggestions: go ahead.\n\nCiao,\nDscho\n"},{"id":"35036","messageId":"Pine.LNX.4.64.0702191450580.20368@woody.linux-foundation.org","threadId":"6861","inReplyTo":"20070217233203.GA6014@coredump.intra.peff.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-19T22:57:23Z","receivedAt":"2007-02-19T22:57:23Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 17 Feb 2007, Jeff King wrote:\n>\n> On Sat, Feb 17, 2007 at 03:31:18PM -0800, Junio C Hamano wrote:\n> \n> > I thought about that, but decided against it. If you are truly\n> > operating outside a git managed repository, it does not feel\n> > right to apply configuration user has for git.\n> \n> Then why are they using git-apply, and not patch?\n\nI don't know about others, but I use \"git apply\" even outside git (*) \nsimply because the defaults for it are a lot better than \"patch\".\n\nI've always hated how patch has some _really_ unsafe default behaviour:\n\n - it will guess at filenames. As in *totally* guess. If you have a patch \n that touches a Makefile in a subdirectory, but that subdirectory had \n been renamed or removed, it's entirely possible that \"patch\" will \n actually find *another* file called \"Makefile\" (most likely your \n top-most one) and apply the patch to that.\n\n And yes, this has actually happened to me.\n\n - it defaults to various unsafe options, like allowing a big fuzz factor \n (I think it defaults to --fuzz=2), which means that if you've already \n applied the patch, but there was _another_ place that looks a bit like \n the original place, \"patch\" will happily apply it *again* because the \n default fuzz-factor is so permissive.\n\ngit-apply has much saner defaults (it defaults to something pretty safe, \nand you can then make it less safe if the patch doesn't apply).\n\nIt also knows about renames. I hope that some day people will start \nsending rename-patches around, just because they are *so* much more \nreadable than delete/create patches.\n\n\t\tLinus\n\n(*) Although I have also noticed that even more often than using \"git \napply\" outside a git thing, I just import everything into git these days. \nSo I may not have actually used git-apply outside of a git project in a \nlong time any more. But I did, a few times.\n"},{"id":"35038","messageId":"20070219230406.GC27722@spearce.org","threadId":"6861","inReplyTo":"Pine.LNX.4.64.0702191450580.20368@woody.linux-foundation.org","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-19T23:04:06Z","receivedAt":"2007-02-19T23:04:06Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> (*) Although I have also noticed that even more often than using \"git \n> apply\" outside a git thing, I just import everything into git these days. \n> So I may not have actually used git-apply outside of a git project in a \n> long time any more. But I did, a few times.\n\nWhich makes me wonder, have you looked at (or used)\ncontrib/fast-import/import-tars.perl ?\n\nIts Perl, which I know is not your favorite language, but it should\nbe a faster way to get a tar into a Git repository, as we never\nactually extract the files from the tar, or create loose objects.\n\n-- \nShawn.\n"},{"id":"35040","messageId":"7vodnp68p8.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.64.0702191450580.20368@woody.linux-foundation.org","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-19T23:14:59Z","receivedAt":"2007-02-19T23:14:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> I don't know about others, but I use \"git apply\" even outside git (*) \n> simply because the defaults for it are a lot better than \"patch\".\n>\n> I've always hated how patch has some _really_ unsafe default behaviour:\n> ...\n> git-apply has much saner defaults (it defaults to something pretty safe, \n> and you can then make it less safe if the patch doesn't apply).\n\nAll true.\n\n> It also knows about renames. I hope that some day people will start \n> sending rename-patches around, just because they are *so* much more \n> readable than delete/create patches.\n\nI've seen a few on git list and I think I saw a couple on kernel\nlist as well in the past.\n\nBy the way, do you want to veto a related change that makes\ngit-apply behave consistently between:\n\n\t$ cd sub/directory\n $ git apply patch.file\n\nand\n\n\t$ cd sub/directory\n $ git apply --index patch.file\n\nThe issue is, that \"patch.file\" (typically) starts with:\n\n\tdiff a/sub/directory/Makefile b/sub/directory/Makefile\n\t--- a/sub/directory/Makefile\n\t+++ b/sub/directory/Makefile\n\nand the form without --index would say \"What are you talking\nabout? I do not see sub/directory/Makefile\".\n\nI consider this is a bugfix, but it does change the behaviour,\nso I am a bit worried about possible fallout.\n"},{"id":"35043","messageId":"Pine.LNX.4.64.0702191527320.20368@woody.linux-foundation.org","threadId":"6861","inReplyTo":"7vodnp68p8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-19T23:37:35Z","receivedAt":"2007-02-19T23:37:35Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 19 Feb 2007, Junio C Hamano wrote:\n> > ...\n> > git-apply has much saner defaults (it defaults to something pretty safe, \n> > and you can then make it less safe if the patch doesn't apply).\n> \n> All true.\n\nOne thing I forgot to mention: \"git apply\" doesn't apply *anything* unless \neverything applies cleanly. In contrast, when \"patch\" fails in the middle, \nit will have done part of the job, and then leaves a reject file. I much \nprefer the \"everything or nothing\" approach of git-apply (again, obviously \nwith \"--reject\" you can make it work the bad old way too).\n\n> By the way, do you want to veto a related change that makes\n> git-apply behave consistently between:\n> \n> \t$ cd sub/directory\n> $ git apply patch.file\n> \n> and\n> \n> \t$ cd sub/directory\n> $ git apply --index patch.file\n> \n> The issue is, that \"patch.file\" (typically) starts with:\n> \n> \tdiff a/sub/directory/Makefile b/sub/directory/Makefile\n> \t--- a/sub/directory/Makefile\n> \t+++ b/sub/directory/Makefile\n> \n> and the form without --index would say \"What are you talking\n> about? I do not see sub/directory/Makefile\".\n> \n> I consider this is a bugfix, but it does change the behaviour,\n> so I am a bit worried about possible fallout.\n\nAhh.. I'm not going to veto it, although I have to admit that I don't know \nwhat the \"right answer\" is, or if a \"right answer\" really exists.\n\nI _think_ that the right answer is to (a) yes, make it be consistent, but \n(b) _not_ make it be the way we do \"--index\" now.\n\nRight now, when we see \"--index\", we do the \"setup_git_directory()\" and \nthe git_config() stuff - which is (I think) something we should always do, \nbut then we do *not* prefix the patch itself with the prefix we got. And I \nthink that's wrong. I think we should always do the \"-p1\" behaviour from \nwhere we started.\n\nThen, if somebody is in a sub/directory/, maybe they need to add a \"-p3\" \nto indicate that, but at least that's better than having a patch that just \nsays \"Makefile\", and applying the patch to the *wrong* \"Makefile\" \n(top-level one, rather than the one you were in).\n\nHmm?\n\n\t\tLinus\n"},{"id":"35046","messageId":"7vwt2d4s6c.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.64.0702191527320.20368@woody.linux-foundation.org","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-19T23:57:15Z","receivedAt":"2007-02-19T23:57:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 19 Feb 2007, Junio C Hamano wrote:\n>> > ...\n>> > git-apply has much saner defaults (it defaults to something pretty safe, \n>> > and you can then make it less safe if the patch doesn't apply).\n>> \n>> All true.\n>\n> One thing I forgot to mention: \"git apply\" doesn't apply *anything* unless \n> everything applies cleanly. In contrast, when \"patch\" fails in the middle, \n> it will have done part of the job, and then leaves a reject file. I much \n> prefer the \"everything or nothing\" approach of git-apply (again, obviously \n> with \"--reject\" you can make it work the bad old way too).\n\nYup.\n\n> I _think_ that the right answer is to (a) yes, make it be consistent, but \n> (b) _not_ make it be the way we do \"--index\" now.\n>\n> Right now, when we see \"--index\", we do the \"setup_git_directory()\" and \n> the git_config() stuff - which is (I think) something we should always do, \n> but then we do *not* prefix the patch itself with the prefix we got. And I \n> think that's wrong. I think we should always do the \"-p1\" behaviour from \n> where we started.\n\nHmm. I am puzzled. Are you suggesting to change behaviour of\n\"git apply\" with --index?\n\ngit generated patch, or patches on the kernel list that are not\ngenerated with git are always relative to the top-level, so I\nthink the current --index behaviour makes tons of sense.\n\n> Then, if somebody is in a sub/directory/, maybe they need to add a \"-p3\" \n> to indicate that, but at least that's better than having a patch that just \n> says \"Makefile\", and applying the patch to the *wrong* \"Makefile\" \n> (top-level one, rather than the one you were in).\n>\n> Hmm?\n\nI think it boils down to this question: when you have a patch on\nhand that you are considering to apply to your tree, if the\npatch talks about just \"Makefile\" (e.g. it says \"a/Makefile\nb/Makefile\") which Makefile is more likely to be what the patch\nis talking about -- the toplevel one or the one in the\nsubdirectory you happen to be in?\n\nBoth (1) diff generated by git are always relative to top, and\n(2) the BCP on the kernel list (and I suspect many other\nprojects are run this way as well) is to have diff relative to\nthe toplevel, suggests that \"a/Makefile b/Makefile\" patch is\nmuch more likely to be about the top-level Makefile no matter\nwhere you happen to be.\n\nAlthough the fact you *are* in the subdirectory when you are\nconsidering that patch makes it a bit more plausible than\notherwise that the patch may be about sub/directory/Makefile, I\ndo not think that is strong enough hint to make it more\nplausible to apply to the sub/directory one than to the\ntoplevel.\n\nIf the patch were what you made by running \"GNU diff\" inside a\ncorresponding subdirectory of another repository (perhaps you\nwanted to feed uncommitted changes from there to this\nrepository), then you can always use \"GNU patch\" to apply. If\nyou made such a one-shot patch using git-diff, it will tell you\nthe correct directory to apply to, so...\n"},{"id":"35048","messageId":"Pine.LNX.4.64.0702191601300.20368@woody.linux-foundation.org","threadId":"6861","inReplyTo":"7vwt2d4s6c.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-20T00:11:02Z","receivedAt":"2007-02-20T00:11:02Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 19 Feb 2007, Junio C Hamano wrote:\n> \n> Hmm. I am puzzled. Are you suggesting to change behaviour of\n> \"git apply\" with --index?\n\nYeah. Or at least _verify_ that the patch is within the subdirectory we \nare in right now. Right now, we do neither, and it will actually change \nfiles outside that subdirectory, which I think is a bit dangerous.\n\n> git generated patch, or patches on the kernel list that are not\n> generated with git are always relative to the top-level, so I\n> think the current --index behaviour makes tons of sense.\n\nI agree that it is sensible, but it's sensible only within the context of \npurely self-generated patches, where the patch itself was generated not \njust with git, but with that exact project.\n\nImagine somebody sending you a patch to a set of files, and they didn't \nuse git to generate that patch. What would it look right? Right, it might \nwell look like\n\n\tdiff -u file.c.orig file.c\n\t--- file.c.orig\n\t+++ file.c\n\t@@ -29,6 +29,7 @@\n\t...\n\nand it happens to be in some subdirectory. What would you do?\n\nI'd use \"git apply\". And I would be really upset *if* git-apply actually \napplied the patch to some *other* subdirectory than the one I was in.\n\n(Again, \"Makefile\" is a common case, since you often have it at multiple \nlevels - maybe it would try to apply the changes to the top-level \nMakefile, even though I was in the drivers/usb/ subdirectory).\n\nNow, I personally actually always work in the top-level directory, so I \ndon't actually much care. I'm so used to editing the patches themselves \nthat that is what I always end up doing, but I do believe that I'm odd in \nthat. Few enough people have worked with unified diffs for over 15 years, \nand are perfectly happy to edit not just the headers, but the actual \ncontents too, and fixing up the line numbers to make it all come out \nright. I do that regularly (not daily, but I probably do it almost once a \nmonth - I decide that I like somebody's patch and want to apply it, but \nfix up some whitespace issue in the patch where he had the opening brace \nof an \"if\"-statement on the wrong line etc).\n\nSo while I *personally* would probably never be impacted, just because I \nalway work in the top directory anyway, I do that partly exactly because \nI'm the top-level maintainer. Somebody who maintains drivers/usb/ might \nwell get patches to a driver that only edits the xyzzy.c and xyzzy.h files \nwithin that subdirectory, and it really does make sense that he be able to \ndo \"git apply < patch\" in that situation.\n\n\t\tLinus\n"},{"id":"35050","messageId":"Pine.LNX.4.63.0702200112500.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6861","inReplyTo":"7vwt2d4s6c.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-20T00:16:59Z","receivedAt":"2007-02-20T00:16:59Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 19 Feb 2007, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > On Mon, 19 Feb 2007, Junio C Hamano wrote:\n> >> > ...\n> >> > git-apply has much saner defaults (it defaults to something pretty safe, \n> >> > and you can then make it less safe if the patch doesn't apply).\n> >> \n> >> All true.\n> >\n> > One thing I forgot to mention: \"git apply\" doesn't apply *anything* unless \n> > everything applies cleanly. In contrast, when \"patch\" fails in the middle, \n> > it will have done part of the job, and then leaves a reject file. I much \n> > prefer the \"everything or nothing\" approach of git-apply (again, obviously \n> > with \"--reject\" you can make it work the bad old way too).\n> \n> Yup.\n\nThat is important to keep in mind for the following:\n\n> > I _think_ that the right answer is to (a) yes, make it be consistent, but \n> > (b) _not_ make it be the way we do \"--index\" now.\n\nBTW this is what I argued, too. But I am not hard minded.\n\n> > Right now, when we see \"--index\", we do the \"setup_git_directory()\" \n> > and the git_config() stuff - which is (I think) something we should \n> > always do, but then we do *not* prefix the patch itself with the \n> > prefix we got. And I think that's wrong. I think we should always do \n> > the \"-p1\" behaviour from where we started.\n> \n> Hmm. I am puzzled. Are you suggesting to change behaviour of \"git \n> apply\" with --index?\n> \n> git generated patch, or patches on the kernel list that are not \n> generated with git are always relative to the top-level, so I think the \n> current --index behaviour makes tons of sense.\n\nBut not all patches are generated by git. Unfortunately.\n\n> > Then, if somebody is in a sub/directory/, maybe they need to add a \n> > \"-p3\" to indicate that, but at least that's better than having a patch \n> > that just says \"Makefile\", and applying the patch to the *wrong* \n> > \"Makefile\" (top-level one, rather than the one you were in).\n> \n> I think it boils down to this question: when you have a patch on\n> hand that you are considering to apply to your tree, if the\n> patch talks about just \"Makefile\" (e.g. it says \"a/Makefile\n> b/Makefile\") which Makefile is more likely to be what the patch\n> is talking about -- the toplevel one or the one in the\n> subdirectory you happen to be in?\n> \n> Both (1) diff generated by git are always relative to top, and\n> (2) the BCP on the kernel list (and I suspect many other\n> projects are run this way as well) is to have diff relative to\n> the toplevel, suggests that \"a/Makefile b/Makefile\" patch is\n> much more likely to be about the top-level Makefile no matter\n> where you happen to be.\n> \n> Although the fact you *are* in the subdirectory when you are\n> considering that patch makes it a bit more plausible than\n> otherwise that the patch may be about sub/directory/Makefile, I\n> do not think that is strong enough hint to make it more\n> plausible to apply to the sub/directory one than to the\n> toplevel.\n> \n> If the patch were what you made by running \"GNU diff\" inside a\n> corresponding subdirectory of another repository (perhaps you\n> wanted to feed uncommitted changes from there to this\n> repository), then you can always use \"GNU patch\" to apply. If\n> you made such a one-shot patch using git-diff, it will tell you\n> the correct directory to apply to, so...\n\n... and here we come back to the argument that git-apply is so much saner \nthan patch.\n\nAnd yes, it happened to me a while ago that I used \"patch\", cursed for a \nlittle moment, said \"git reset --hard\" and cursed even more when I \nrealized that I was not in a git-tracked working directory!\n\nMy vote is for \"take the current subdirectory as root for the patch\", \nsince that is what I'd expect out of the box. But as I said: I am not \n_that_ hard minded, at least on this issue.\n\nCiao,\nDscho\n"},{"id":"35056","messageId":"7vps854qf8.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.64.0702191601300.20368@woody.linux-foundation.org","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-20T00:35:07Z","receivedAt":"2007-02-20T00:35:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> I agree that it is sensible, but it's sensible only within the context of \n> purely self-generated patches, where the patch itself was generated not \n> just with git, but with that exact project.\n\nThat makes sense, except that the patch could be made with any\nother tools; it just has to follow the \"patch is from the top of\nthe tree, with -p1\" convention.\n\nI think it might make sense to change (this might have to be\nread \"break\", unfortunately) \"git apply\" for all three cases.\n\nSo the new rule, which would affect only when you run from a\nsubdirectory, would be that \"diff -u a/foo b/foo\" would be\nparsed, 1 level (or -p levels) of leading paths stripped,\nand then prefix is added to form \"new\" and \"old\" filenames.\n\nAnd I think Johannes is happy with that change as well.\n"},{"id":"35058","messageId":"45DA4298.7010002@fs.ei.tum.de","threadId":"6861","inReplyTo":"7vwt2d4s6c.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-02-20T00:36:40Z","receivedAt":"2007-02-20T00:36:40Z","isPatch":true,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> If the patch were what you made by running \"GNU diff\" inside a\n> corresponding subdirectory of another repository (perhaps you\n> wanted to feed uncommitted changes from there to this\n> repository), then you can always use \"GNU patch\" to apply. If\n> you made such a one-shot patch using git-diff, it will tell you\n> the correct directory to apply to, so...\n\nThe difference there is that GNU/Larry Wall diff does not prepend a/ and b/ to the paths. Maybe use this as an indicator for \"this patch is relative to project root\" vs. \"this patch doesn't know where it wants to be applied\".\n\nA parameter --subdir, or even plain -pN could mean \"apply this patch here, now.\"\n\ncheers\n simon\n\n-- \nServe - BSD +++ RENT this banner advert +++ ASCII Ribbon /\"\\\nWork - Mac +++ space for low €€€ NOW!1 +++ Campaign \\ /\nParty Enjoy Relax | http://dragonflybsd.org Against HTML \\\nDude 2c 2 the max ! http://golden-apple.biz Mail + News / \\\n\n"},{"id":"35067","messageId":"Pine.LNX.4.63.0702200152230.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6861","inReplyTo":"7vps854qf8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-20T00:53:04Z","receivedAt":"2007-02-20T00:53:04Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 19 Feb 2007, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > I agree that it is sensible, but it's sensible only within the context of \n> > purely self-generated patches, where the patch itself was generated not \n> > just with git, but with that exact project.\n> \n> That makes sense, except that the patch could be made with any\n> other tools; it just has to follow the \"patch is from the top of\n> the tree, with -p1\" convention.\n> \n> I think it might make sense to change (this might have to be\n> read \"break\", unfortunately) \"git apply\" for all three cases.\n\nJust for the subdirectory case.\n\n> So the new rule, which would affect only when you run from a \n> subdirectory, would be that \"diff -u a/foo b/foo\" would be parsed, 1 \n> level (or -p levels) of leading paths stripped, and then prefix is \n> added to form \"new\" and \"old\" filenames.\n\nWouldn't it be easier to just cd to the prefix?\n\n> And I think Johannes is happy with that change as well.\n\nYes, thank you.\n\nCiao,\nDscho\n"},{"id":"35070","messageId":"7v7iud4nyo.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.64.0702191601300.20368@woody.linux-foundation.org","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-20T01:28:15Z","receivedAt":"2007-02-20T01:28:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 19 Feb 2007, Junio C Hamano wrote:\n>> \n>> Hmm. I am puzzled. Are you suggesting to change behaviour of\n>> \"git apply\" with --index?\n>\n> Yeah. Or at least _verify_ that the patch is within the subdirectory we \n> are in right now. Right now, we do neither, and it will actually change \n> files outside that subdirectory, which I think is a bit dangerous.\n\nI think use_patch() has always took care of that.\n"},{"id":"35071","messageId":"7v3b514nx4.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.63.0702200152230.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-20T01:29:11Z","receivedAt":"2007-02-20T01:29:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Wouldn't it be easier to just cd to the prefix?\n\nI do not think so. Think of what you need to do to the index.\n"},{"id":"35073","messageId":"Pine.LNX.4.64.0702191737150.20368@woody.linux-foundation.org","threadId":"6861","inReplyTo":"7v7iud4nyo.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-20T01:38:17Z","receivedAt":"2007-02-20T01:38:17Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 19 Feb 2007, Junio C Hamano wrote:\n> \n> I think use_patch() has always took care of that.\n\nAhh, right you are. \n\n\t\tLinus\n"},{"id":"35074","messageId":"Pine.LNX.4.63.0702200243140.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6861","inReplyTo":"7v3b514nx4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-20T01:43:29Z","receivedAt":"2007-02-20T01:43:29Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 19 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Wouldn't it be easier to just cd to the prefix?\n> \n> I do not think so. Think of what you need to do to the index.\n\nOuch. I did not even think of that. You're right.\n\nCiao,\nDscho\n"},{"id":"35076","messageId":"7vr6sl381i.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"7vps854qf8.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] git-apply: require -p when working in a subdirectory.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-20T01:57:29Z","receivedAt":"2007-02-20T01:57:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"git-apply running inside a subdirectory, with or without --index,\nused to always assume that the patch is formatted in such a way\nto apply with -p1 from the toplevel, but it is more useful and\nconsistent with the use of \"GNU patch -p1\" if it defaulted to\nassume that its input is meant to apply at the level it is\ninvoked in.\n\nThis changes the behaviour. It used to be that the patch\ngenerated this way would apply without any trick:\n\n\tedit Documentation/Makefile\n\tgit diff >patch.file\n\tcd Documentation\n\tgit apply ../patch.file\n\nYou need to give an explicit -p2 to git-apply now. On the other\nhand, if you got a patch from somebody else who did not follow\n\"patch is to apply from the top with -p1\" convention, the input\npatch would start with:\n\n\tdiff -u Makefile.old Makefile\n\t--- Makefile.old\n\t+++ Makefile\n\nand in such a case, you can apply it with:\n\n\tgit apply -p0 patch.file\n\nSigned-off-by: Junio C Hamano \n---\n\n * This also makes \"git apply\" to honor -p option even on git\n generated patches (\"diff --git\").\n\n builtin-apply.c | 46 ++++++++++++++++++++++++++++++----------------\n t/t4119-apply-config.sh | 32 ++++++++++++++++++--------------\n 2 files changed, 48 insertions(+), 30 deletions(-)\n\ndiff --git a/builtin-apply.c b/builtin-apply.c\nindex 6153791..53f286e 100644\n--- a/builtin-apply.c\n+++ b/builtin-apply.c\n@@ -238,7 +238,7 @@ static int name_terminate(const char *name, int namelen, int c, int terminate)\n \treturn 1;\n }\n \n-static char * find_name(const char *line, char *def, int p_value, int terminate)\n+static char *find_name(const char *line, char *def, int p_value, int terminate)\n {\n \tint len;\n \tconst char *start = line;\n@@ -362,7 +362,7 @@ static int gitdiff_hdrend(const char *line, struct patch *patch)\n static char *gitdiff_verify_name(const char *line, int isnull, char *orig_name, const char *oldnew)\n {\n \tif (!orig_name && !isnull)\n-\t\treturn find_name(line, NULL, 1, TERM_TAB);\n+\t\treturn find_name(line, NULL, p_value, TERM_TAB);\n \n \tif (orig_name) {\n \t\tint len;\n@@ -372,7 +372,7 @@ static char *gitdiff_verify_name(const char *line, int isnull, char *orig_name,\n \t\tlen = strlen(name);\n \t\tif (isnull)\n \t\t\tdie(\"git-apply: bad git-diff - expected /dev/null, got %s on line %d\", name, linenr);\n-\t\tanother = find_name(line, NULL, 1, TERM_TAB);\n+\t\tanother = find_name(line, NULL, p_value, TERM_TAB);\n \t\tif (!another || memcmp(another, name, len))\n \t\t\tdie(\"git-apply: bad git-diff - inconsistent %s filename on line %d\", oldnew, linenr);\n \t\tfree(another);\n@@ -427,28 +427,28 @@ static int gitdiff_newfile(const char *line, struct patch *patch)\n static int gitdiff_copysrc(const char *line, struct patch *patch)\n {\n \tpatch->is_copy = 1;\n-\tpatch->old_name = find_name(line, NULL, 0, 0);\n+\tpatch->old_name = find_name(line, NULL, p_value-1, 0);\n \treturn 0;\n }\n \n static int gitdiff_copydst(const char *line, struct patch *patch)\n {\n \tpatch->is_copy = 1;\n-\tpatch->new_name = find_name(line, NULL, 0, 0);\n+\tpatch->new_name = find_name(line, NULL, p_value-1, 0);\n \treturn 0;\n }\n \n static int gitdiff_renamesrc(const char *line, struct patch *patch)\n {\n \tpatch->is_rename = 1;\n-\tpatch->old_name = find_name(line, NULL, 0, 0);\n+\tpatch->old_name = find_name(line, NULL, p_value-1, 0);\n \treturn 0;\n }\n \n static int gitdiff_renamedst(const char *line, struct patch *patch)\n {\n \tpatch->is_rename = 1;\n-\tpatch->new_name = find_name(line, NULL, 0, 0);\n+\tpatch->new_name = find_name(line, NULL, p_value-1, 0);\n \treturn 0;\n }\n \n@@ -2394,7 +2394,7 @@ static void write_out_one_result(struct patch *patch, int phase)\n {\n \tif (patch->is_delete > 0) {\n \t\tif (phase == 0)\n-\t\t\tremove_file(patch);\n+\t\t\tremove_file(patch, 1);\n \t\treturn;\n \t}\n \tif (patch->is_new > 0 || patch->is_copy) {\n@@ -2407,7 +2407,7 @@ static void write_out_one_result(struct patch *patch, int phase)\n \t * thing: remove the old, write the new\n \t */\n \tif (phase == 0)\n-\t\tremove_file(patch);\n+\t\tremove_file(patch, 0);\n \tif (phase == 1)\n \t\tcreate_file(patch);\n }\n@@ -2520,15 +2520,26 @@ static int use_patch(struct patch *p)\n \t\t\treturn 0;\n \t\tx = x->next;\n \t}\n-\tif (0 < prefix_length) {\n-\t\tint pathlen = strlen(pathname);\n-\t\tif (pathlen <= prefix_length ||\n-\t\t memcmp(prefix, pathname, prefix_length))\n-\t\t\treturn 0;\n-\t}\n \treturn 1;\n }\n \n+static char *prefix_one(char *name)\n+{\n+\tif (!name)\n+\t\treturn name;\n+\treturn xstrdup(prefix_filename(prefix, prefix_length, name));\n+}\n+\n+static void prefix_patches(struct patch *p)\n+{\n+\tif (!prefix)\n+\t\treturn;\n+\tfor ( ; p; p = p->next) {\n+\t\tp->new_name = prefix_one(p->new_name);\n+\t\tp->old_name = prefix_one(p->old_name);\n+\t}\n+}\n+\n static int apply_patch(int fd, const char *filename, int inaccurate_eof)\n {\n \tunsigned long offset, size;\n@@ -2551,11 +2562,14 @@ static int apply_patch(int fd, const char *filename, int inaccurate_eof)\n \t\t\tbreak;\n \t\tif (apply_in_reverse)\n \t\t\treverse_patches(patch);\n+\t\tif (prefix)\n+\t\t\tprefix_patches(patch);\n \t\tif (use_patch(patch)) {\n \t\t\tpatch_stats(patch);\n \t\t\t*listp = patch;\n \t\t\tlistp = &patch->next;\n-\t\t} else {\n+\t\t}\n+\t\telse {\n \t\t\t/* perhaps free it a bit better? */\n \t\t\tfree(patch);\n \t\t\tskipped_patch++;\ndiff --git a/t/t4119-apply-config.sh b/t/t4119-apply-config.sh\nindex 0e8ea7e..816b5b8 100755\n--- a/t/t4119-apply-config.sh\n+++ b/t/t4119-apply-config.sh\n@@ -10,20 +10,22 @@ test_description='git-apply --whitespace=strip and configuration file.\n . ./test-lib.sh\n \n test_expect_success setup '\n-\techo A >file1 &&\n-\tcp file1 saved &&\n-\tgit add file1 &&\n-\techo \"B \" >file1 &&\n+\tmkdir sub &&\n+\techo A >sub/file1 &&\n+\tcp sub/file1 saved &&\n+\tgit add sub/file1 &&\n+\techo \"B \" >sub/file1 &&\n \tgit diff >patch.file\n '\n \n test_expect_success 'apply --whitespace=strip' '\n \n-\tcp saved file1 &&\n+\trm -f sub/file1 &&\n+\tcp saved sub/file1 &&\n \tgit update-index --refresh &&\n \n \tgit apply --whitespace=strip patch.file &&\n-\tif grep \" \" file1\n+\tif grep \" \" sub/file1\n \tthen\n \t\techo \"Eh?\"\n \t\tfalse\n@@ -34,12 +36,13 @@ test_expect_success 'apply --whitespace=strip' '\n \n test_expect_success 'apply --whitespace=strip from config' '\n \n-\tcp saved file1 &&\n+\trm -f sub/file1 &&\n+\tcp saved sub/file1 &&\n \tgit update-index --refresh &&\n \n \tgit config apply.whitespace strip &&\n \tgit apply patch.file &&\n-\tif grep \" \" file1\n+\tif grep \" \" sub/file1\n \tthen\n \t\techo \"Eh?\"\n \t\tfalse\n@@ -48,19 +51,19 @@ test_expect_success 'apply --whitespace=strip from config' '\n \tfi\n '\n \n-mkdir sub\n D=`pwd`\n \n test_expect_success 'apply --whitespace=strip in subdir' '\n \n \tcd \"$D\" &&\n \tgit config --unset-all apply.whitespace\n-\tcp saved file1 &&\n+\trm -f sub/file1 &&\n+\tcp saved sub/file1 &&\n \tgit update-index --refresh &&\n \n \tcd sub &&\n-\tgit apply --whitespace=strip ../patch.file &&\n-\tif grep \" \" ../file1\n+\tgit apply --whitespace=strip -p2 ../patch.file &&\n+\tif grep \" \" file1\n \tthen\n \t\techo \"Eh?\"\n \t\tfalse\n@@ -73,11 +76,12 @@ test_expect_success 'apply --whitespace=strip from config in subdir' '\n \n \tcd \"$D\" &&\n \tgit config apply.whitespace strip &&\n-\tcp saved file1 &&\n+\trm -f sub/file1 &&\n+\tcp saved sub/file1 &&\n \tgit update-index --refresh &&\n \n \tcd sub &&\n-\tgit apply ../patch.file &&\n+\tgit apply -p2 ../patch.file &&\n \tif grep \" \" file1\n \tthen\n \t\techo \"Eh?\"\n-- \n1.5.0.1.555.g13b30\n"},{"id":"35077","messageId":"7vk5yd37z1.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"7vps854qf8.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] git-apply: do not lose cwd when run from a subdirectory.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-20T01:58:58Z","receivedAt":"2007-02-20T01:58:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When a patch modifies (not deletes) the last file in a\ndirectory, because we treat a modification just as deletion\nfollowed by creation, and deleting the last file in a directory\nautomatically rmdir(2)'s that directory, we ended up removing\nthe directory, which can potentially be the cwd, and then\nrecreating the same directory to create the patch result.\n\nAvoid the rmdir step when remove_file() is called only because\nwe are replacing it with the result by later calling\ncreate_file().\n\nSigned-off-by: Junio C Hamano \n---\n\n * This is not related to the previous patch, but the updated\n test trigeers it ;-).\n\n builtin-apply.c | 4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin-apply.c b/builtin-apply.c\nindex 20fb5bd..6153791 100644\n--- a/builtin-apply.c\n+++ b/builtin-apply.c\n@@ -2243,7 +2243,7 @@ static void patch_stats(struct patch *patch)\n \t}\n }\n \n-static void remove_file(struct patch *patch)\n+static void remove_file(struct patch *patch, int rmdir_empty)\n {\n \tif (write_index) {\n \t\tif (remove_file_from_cache(patch->old_name) < 0)\n@@ -2251,7 +2251,7 @@ static void remove_file(struct patch *patch)\n \t\tcache_tree_invalidate_path(active_cache_tree, patch->old_name);\n \t}\n \tif (!cached) {\n-\t\tif (!unlink(patch->old_name)) {\n+\t\tif (!unlink(patch->old_name) && rmdir_empty) {\n \t\t\tchar *name = xstrdup(patch->old_name);\n \t\t\tchar *end = strrchr(name, '/');\n \t\t\twhile (end) {\n-- \n1.5.0.1.555.g13b30\n"},{"id":"35080","messageId":"Pine.LNX.4.63.0702200332090.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6861","inReplyTo":"7vr6sl381i.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH] apply: fix memory leak in prefix_one()","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-20T02:33:09Z","receivedAt":"2007-02-20T02:33:09Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nSigned-off-by: Johannes Schindelin \n---\n\n\tThank you for your patches. (BTW they _are_ dependent, since\n\tthe signature of remove_file() has changed.)\n\n\tThis is on top of them.\n\n builtin-apply.c | 14 ++++++++------\n 1 files changed, 8 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin-apply.c b/builtin-apply.c\nindex e01969f..02b7ed9 100644\n--- a/builtin-apply.c\n+++ b/builtin-apply.c\n@@ -2516,11 +2516,13 @@ static int use_patch(struct patch *p)\n \treturn 1;\n }\n \n-static char *prefix_one(char *name)\n+static void prefix_one(char **name)\n {\n-\tif (!name)\n-\t\treturn name;\n-\treturn xstrdup(prefix_filename(prefix, prefix_length, name));\n+\tchar *old_name = *name;\n+\tif (!old_name)\n+\t\treturn;\n+\t*name = xstrdup(prefix_filename(prefix, prefix_length, *name));\n+\tfree(old_name);\n }\n \n static void prefix_patches(struct patch *p)\n@@ -2528,8 +2530,8 @@ static void prefix_patches(struct patch *p)\n \tif (!prefix)\n \t\treturn;\n \tfor ( ; p; p = p->next) {\n-\t\tp->new_name = prefix_one(p->new_name);\n-\t\tp->old_name = prefix_one(p->old_name);\n+\t\tprefix_one(&p->new_name);\n+\t\tprefix_one(&p->old_name);\n \t}\n }\n \n-- \n1.5.0.1.2143.g4dac-dirty\n"},{"id":"35081","messageId":"7vbqjp3630.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.63.0702200332090.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] apply: fix memory leak in prefix_one()","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-20T02:39:47Z","receivedAt":"2007-02-20T02:39:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> \tThis is on top of them.\n\nI am not sure if this is correct. Don't we do some point\nnew_name = old_name = blah?\n"},{"id":"35082","messageId":"Pine.LNX.4.63.0702200345070.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6861","inReplyTo":"7vbqjp3630.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] apply: fix memory leak in prefix_one()","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-20T02:45:49Z","receivedAt":"2007-02-20T02:45:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 19 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > \tThis is on top of them.\n> \n> I am not sure if this is correct. Don't we do some point\n> new_name = old_name = blah?\n\nYes, you're right. I missed that. The change is in the last hunk:\n\n--\n\n[PATCH] apply: fix memory leak in prefix_one()\n\nSigned-off-by: Johannes Schindelin \n---\n builtin-apply.c | 15 +++++++++------\n 1 files changed, 9 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin-apply.c b/builtin-apply.c\nindex e01969f..2a23138 100644\n--- a/builtin-apply.c\n+++ b/builtin-apply.c\n@@ -2516,11 +2516,13 @@ static int use_patch(struct patch *p)\n \treturn 1;\n }\n \n-static char *prefix_one(char *name)\n+static void prefix_one(char **name)\n {\n-\tif (!name)\n-\t\treturn name;\n-\treturn xstrdup(prefix_filename(prefix, prefix_length, name));\n+\tchar *old_name = *name;\n+\tif (!old_name)\n+\t\treturn;\n+\t*name = xstrdup(prefix_filename(prefix, prefix_length, *name));\n+\tfree(old_name);\n }\n \n static void prefix_patches(struct patch *p)\n@@ -2528,8 +2530,9 @@ static void prefix_patches(struct patch *p)\n \tif (!prefix)\n \t\treturn;\n \tfor ( ; p; p = p->next) {\n-\t\tp->new_name = prefix_one(p->new_name);\n-\t\tp->old_name = prefix_one(p->old_name);\n+\t\tif (p->new_name != p->old_name)\n+\t\t\tprefix_one(&p->new_name);\n+\t\tprefix_one(&p->old_name);\n \t}\n }\n \n-- \n1.5.0.1.2141.gc066\n"},{"id":"35159","messageId":"Pine.LNX.4.64.0702210014140.6485@iabervon.org","threadId":"6861","inReplyTo":"Pine.LNX.4.64.0702191601300.20368@woody.linux-foundation.org","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-02-21T05:39:16Z","receivedAt":"2007-02-21T05:39:16Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 19 Feb 2007, Linus Torvalds wrote:\n\n> Imagine somebody sending you a patch to a set of files, and they didn't \n> use git to generate that patch. What would it look right? Right, it might \n> well look like\n> \n> \tdiff -u file.c.orig file.c\n> \t--- file.c.orig\n> \t+++ file.c\n> \t@@ -29,6 +29,7 @@\n> \t...\n> \n> and it happens to be in some subdirectory. What would you do?\n> \n> I'd use \"git apply\". And I would be really upset *if* git-apply actually \n> applied the patch to some *other* subdirectory than the one I was in.\n\n\"git apply\" should be able to notice the many clues that this patch \ndoesn't go at the root: (1) it's not -r; (2) it's not a rename, but the \nfilenames aren't the same; (3) there isn't an extra path element to \nremove.\n\nWouldn't the patch author have to do something like \n\"cd drivers; diff -ur usb.orig usb > patch\" (i.e., have old and new \n_directories_ in the _same_ source tree, rather than just files, or \nseparate source trees) in order to generate a patch that would be confusing?\n\nI think \"git apply\" should just know that if the filenames don't match, \nand it's not a rename, and the --- filename isn't /dev/null, then add the \ncurrent directory and use -p0.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"35174","messageId":"7vmz37pxf8.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.64.0702210014140.6485@iabervon.org","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-21T11:22:51Z","receivedAt":"2007-02-21T11:22:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> \"git apply\" should be able to notice the many clues that this patch \n> doesn't go at the root: (1) it's not -r; (2) it's not a rename, but the \n> filenames aren't the same; (3) there isn't an extra path element to \n> remove.\n\nI would sort-of agree with (1) and (3) but people can do\n\n\tcd drivers && diff -u Makefile~ Makefile\n\nso (2) is not a good clue and (3) is not really either.\n\nEspecially files like 'Makefile' are everywhere that dwimming\nand getting it wrong is worse than being stupid but consistent.\n\nWe do -p1 by default because the BCP on the kernel list (which\nis where git came from -- but I suspect many projects follow the\nconvention) is to use \"diff a/dir/file b/dir/file\". This is\nalso a convenient setup for people who apply git generated (or\nBCP formatted) patches from the toplevel of the tree.\n\nBut when you are dealing with handcrafted patches in a\nsubdirectory, such as the one you would get by:\n\n $ cd some/dir && edit file.c && diff -u file.c~ file.c >G.patch\n\nyou do not have the \"a/some/dir b/some/dir\" prefix, so -p1 to\nstrip \"a/\" and \"b/\" is a wrong thing to begin with, but looking\nat G.patch you would not even have \"some/dir\", so no \"correct\"\nvalue exists if we refuse to DWIM (and I refuse to). We support\npath strip levels with -p option ever since you added it with\ne36f8b60, so that is Ok.\n\nHowever, the current version (in v1.5.0.1) of git-apply has a\nfew inconsistencies.\n\n * When --index (or --cached) is given, and when the patch is a\n git generated (or BCP formatted) patch, it finds out where in\n the working tree you are, and strips the right prefix\n automatically.\n\n * When there is no --index nor --cached, however, it does not\n bother to find out where in the working tree your $cwd is,\n and assumes you are at the toplevel (you may not even be in a\n git managed tree but are using git-apply as a better \"patch\",\n in which case there is no way to find out where the toplevel\n is). You need to give -p to explicitly strip the leading\n path. This is not a problem but happens to be a feature to\n help applying handcrafted patches, like G.patch above. Also,\n it is consistent with how GNU patch would behave. However,\n -p is ignored when the patch is a git generated one, which\n is a minor additional problem.\n\nI was initially in favor of correcting this inconsistency by\nmatching the behaviour of non --index/--cached case to that of\nthe behaviour of --index/--cached case (in other words, making\nthings more convenient for people who apply git generated and/or\nBCP formatted patches). But Linus talked me out of it --- and I\nthink he is right.\n\nInconsistency is fixed by making the behaviour more similar to\n\"GNU patch\". The behaviour of --index/--cached case is changed\nso that it does not automatically strip \"some/dir\" part when you\nare in a subdirectory, which is how git-apply without these\noptions operates. Of course, ignoring -p for git generated\npatches no longer makes sense with this change, which is also\nfixed, so you can use the same -p as you would give to \"GNU\npatch\".\n\nWhat is cooking in 'next' should behave the way described above.\nIf not, patches to fix it is very much welcome ;-).\n\nP.S. I think the list hasn't heard from you for quite some\ntime. Welcome back.\n"},{"id":"35181","messageId":"Pine.LNX.4.64.0702210836210.4043@woody.linux-foundation.org","threadId":"6861","inReplyTo":"Pine.LNX.4.64.0702210014140.6485@iabervon.org","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-21T16:44:05Z","receivedAt":"2007-02-21T16:44:05Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 21 Feb 2007, Daniel Barkalow wrote:\n\n> On Mon, 19 Feb 2007, Linus Torvalds wrote:\n> > Imagine somebody sending you a patch to a set of files, and they didn't \n> > use git to generate that patch. What would it look right? Right, it might \n> > well look like\n> > \n> > \tdiff -u file.c.orig file.c\n> > \t--- file.c.orig\n> > \t+++ file.c\n> > \t@@ -29,6 +29,7 @@\n> > \t...\n> > \n> > and it happens to be in some subdirectory. What would you do?\n> > \n> > I'd use \"git apply\". And I would be really upset *if* git-apply actually \n> > applied the patch to some *other* subdirectory than the one I was in.\n> \n> \"git apply\" should be able to notice the many clues that this patch \n> doesn't go at the root: (1) it's not -r; (2) it's not a rename, but the \n> filenames aren't the same; (3) there isn't an extra path element to \n> remove.\n\n(4): it doesn't say \"diff --git\" with all the git-specific info.\n\nWe actually already *do* act differently for native git patches and for \n\"traditional unified diffs\", and yeah, we could certainly extend that to \nthe whole \"what to do about subdirectories\" thing.\n\nFor traditional unified diffs, we already have extra rules about guessing \nthe pathname, so this isn't even really a \"new\" rule, it's just an \nextension of the old ones. With traditional diffs, you *have* to guess at \nthe pathnames, because the pathnames aren't well-defined (never mind \nrenames, it's true for file create/delete events too, and it's true \nexactly because you often have two different filenames for the *same* \nfile, like in my example).\n\n> I think \"git apply\" should just know that if the filenames don't match, \n> and it's not a rename, and the --- filename isn't /dev/null, then add the \n> current directory and use -p0.\n\nWell, \"-p1\" is still the saner default - even unified diff people tend to \nuse that (and if there is no path at all, it's still safe - there's \nnothing to remove).\n\nAs to the traditional vs git patches: we already have totally separate \nfunctions for parsing what they are:\n\n - parse_git_header() parses git-only patches and understands all the \n extended syntax, and has sanity checks\n\n - parse_traditional_patch() has this magic heuristic which knows about \n the \"/dev/null\" special cases, and uses a magic \"find_name()\" function \n that will choose whichever name makes more sense.\n\nWe could just make \"parse_traditional_patch()\" try to take the prefix \ninformation into account instead. That would be a better choice than doing \nit unconditionally even for native git patches.\n\nJunio?\n\n\t\tLinus\n"},{"id":"35185","messageId":"Pine.LNX.4.64.0702211031470.6485@iabervon.org","threadId":"6861","inReplyTo":"7vmz37pxf8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-02-21T17:00:13Z","receivedAt":"2007-02-21T17:00:13Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 21 Feb 2007, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > \"git apply\" should be able to notice the many clues that this patch \n> > doesn't go at the root: (1) it's not -r; (2) it's not a rename, but the \n> > filenames aren't the same; (3) there isn't an extra path element to \n> > remove.\n> \n> I would sort-of agree with (1) and (3) but people can do\n> \n> \tcd drivers && diff -u Makefile~ Makefile\n> \n> so (2) is not a good clue and (3) is not really either.\n\nIn this case you get:\n\n--- Makefile~ 2007-02-16 18:03:16.000000000 -0500\n+++ Makefile 2007-02-19 20:13:18.000000000 -0500\n\nWhich means that the before and after filenames don't agree. And this \nisn't a patch where git can tell what it applies to, so I think (2) is \ngiving the right conclusion in this case. I'm not seeing any case where \n(1), (2), and (3) all don't trigger, and the patch isn't BCP, except for \nthe case I gave in my previous email, which I don't think anyone would \nactually do (if only because it would be confusing and annoying to prepare \nthe change).\n\nSo my contention is that git can reliably detect non-git-formatted/BCP \npatches, and so convenient support for git-formatted/BCP patches is \nbeneficial, because it won't cause git to do the wrong thing.\n\nI think it's as simple as: if apply.c line 290 changes name, the patch \nshouldn't be assumed to be \"absolute\" (-p1 in the repository root). Other \nthan that, I think the patch pretty much has to be \"absolute\", unless the \nauthor has done something really odd. And I think an author who does that \nwill just be misunderstood in general, including by human reviewers.\n\n> However, the current version (in v1.5.0.1) of git-apply has a\n> few inconsistencies.\n> \n> * When --index (or --cached) is given, and when the patch is a\n> git generated (or BCP formatted) patch, it finds out where in\n> the working tree you are, and strips the right prefix\n> automatically.\n> \n> * When there is no --index nor --cached, however, it does not\n> bother to find out where in the working tree your $cwd is,\n> and assumes you are at the toplevel (you may not even be in a\n> git managed tree but are using git-apply as a better \"patch\",\n> in which case there is no way to find out where the toplevel\n> is). You need to give -p to explicitly strip the leading\n> path. This is not a problem but happens to be a feature to\n> help applying handcrafted patches, like G.patch above. Also,\n> it is consistent with how GNU patch would behave. However,\n> -p is ignored when the patch is a git generated one, which\n> is a minor additional problem.\n> \n> I was initially in favor of correcting this inconsistency by\n> matching the behaviour of non --index/--cached case to that of\n> the behaviour of --index/--cached case (in other words, making\n> things more convenient for people who apply git generated and/or\n> BCP formatted patches). But Linus talked me out of it --- and I\n> think he is right.\n> \n> Inconsistency is fixed by making the behaviour more similar to\n> \"GNU patch\". The behaviour of --index/--cached case is changed\n> so that it does not automatically strip \"some/dir\" part when you\n> are in a subdirectory, which is how git-apply without these\n> options operates. Of course, ignoring -p for git generated\n> patches no longer makes sense with this change, which is also\n> fixed, so you can use the same -p as you would give to \"GNU\n> patch\".\n\nI think there are three cases:\n\n - \"absolute\" patch in a git repository. We can tell it's \"absolute\", and \n we know what the project root is, so we know what the correct -p \n level is. We should default to the right answer, and give an error if \n the user specifies something else.\n\n - \"absolute\" patch in a non-git repository. We know the paths of the \n files relative to the repository root, but we need -p to determine \n what the repository root is. We should default to -p1, and let the user\n specify they're running git-apply in a subdirectory with -p.\n\n - non-\"absolute\" patch. We don't know what directory the patch author was \n in, relative to the author's repository root. We should require that \n the user figure it out and use -p to specify the right answer. But \n maybe we could still default to -p1, because it's relatively safe and \n traditional (if it's not right, chances are there won't be any filename \n left, and we'll just give an error).\n\nI think that the only way this would go wrong is if the user is applying \nan \"absolute\" patch to the toplevel Makefile when in a subdirectory of a \nnon-git tree, and expects to get an error message instead of having it try \nto patch the subdirectory Makefile.\n\nI don't see any reason to match GNU patch, because that just means that \nwe're doing something we know is wrong in the first case, and something we \nsuspect is wrong in the third case. \n\nOn the other hand, I agree that the old interpretation of -p wasn't \nright. I think the first case above should change the *default* plevel, \nnot (as it used to) change the interpretation of the default -p1. I.e., if \nyou're in drivers/usb/, and you apply a BCP patch, it should work with -p3 \nand give an error with -p1, but it should also work without a -p \noption.\n\n> P.S. I think the list hasn't heard from you for quite some\n> time. Welcome back.\n\nThanks. :) I've been following the list somewhat, but I've been \ntoo distracted with other projects to get involved with discussions.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"35202","messageId":"7vr6sjnw15.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"Pine.LNX.4.64.0702210836210.4043@woody.linux-foundation.org","subject":"Re: [PATCH] Teach 'git apply' to look at $GIT_DIR/config","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-21T19:35:50Z","receivedAt":"2007-02-21T19:35:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> We could just make \"parse_traditional_patch()\" try to take the prefix \n> information into account instead. That would be a better choice than doing \n> it unconditionally even for native git patches.\n>\n> Junio?\n\nI guess I took your suggestion too literally while being blinded\nby the thought to make things consistent.\n\n>> I _think_ that the right answer is to (a) yes, make it be consistent, but \n>> (b) _not_ make it be the way we do \"--index\" now.\n>>\n>> Right now, when we see \"--index\", we do the \"setup_git_directory()\" and \n>> the git_config() stuff - which is (I think) something we should always do, \n>> but then we do *not* prefix the patch itself with the prefix we got. And I \n>> think that's wrong. I think we should always do the \"-p1\" behaviour from \n>> where we started.\n>\n>Hmm. I am puzzled. Are you suggesting to change behaviour of\n>\"git apply\" with --index?\n\nWe can (and should) obviously do different things depending on\n\"diff --git\". Let me see.\n"},{"id":"35208","messageId":"7vy7mrm9ch.fsf@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"7vr6sjnw15.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] git-apply: notice \"diff --git\" patch again","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-21T22:31:10Z","receivedAt":"2007-02-21T22:31:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Earlier one that tried to be too consistent with GNU patch by\nnot stripping the leading path when we _know_ we are in a\nsubdirectory and the patch is relative to the toplevel was a\nmistake. This fixes it.\n\n - No change to behaviour when it is run from the toplevel of\n the repository.\n\n - When run from a subdirectory to apply a git-generated patch, \n it uses the right -p value automatically, with or without\n --index nor --cached option.\n\n - When run from a subdirectory to apply a randomly generated\n patch, it wants the right -p value to be given by the\n user.\n\nThe second one is a pure improvement to correct inconsistency\nbetween --index and non --index case, compared with 1.5.0. The\nthird point could be further improved to guess what the right\nvalue for -p should be by looking at the patch, but should be\na topic of a separate patch.\n\nSigned-off-by: Junio C Hamano \n---\n builtin-apply.c | 23 ++++++++++++++++-------\n t/t4119-apply-config.sh | 4 ++--\n 2 files changed, 18 insertions(+), 9 deletions(-)\n\ndiff --git a/builtin-apply.c b/builtin-apply.c\nindex 1beebe5..12f00e3 100644\n--- a/builtin-apply.c\n+++ b/builtin-apply.c\n@@ -144,6 +144,7 @@ struct patch {\n \tunsigned long deflate_origlen;\n \tint lines_added, lines_deleted;\n \tint score;\n+\tunsigned int is_toplevel_relative:1;\n \tunsigned int inaccurate_eof:1;\n \tunsigned int is_binary:1;\n \tunsigned int is_copy:1;\n@@ -362,7 +363,7 @@ static int gitdiff_hdrend(const char *line, struct patch *patch)\n static char *gitdiff_verify_name(const char *line, int isnull, char *orig_name, const char *oldnew)\n {\n \tif (!orig_name && !isnull)\n-\t\treturn find_name(line, NULL, p_value, TERM_TAB);\n+\t\treturn find_name(line, NULL, 1, TERM_TAB);\n \n \tif (orig_name) {\n \t\tint len;\n@@ -372,7 +373,7 @@ static char *gitdiff_verify_name(const char *line, int isnull, char *orig_name,\n \t\tlen = strlen(name);\n \t\tif (isnull)\n \t\t\tdie(\"git-apply: bad git-diff - expected /dev/null, got %s on line %d\", name, linenr);\n-\t\tanother = find_name(line, NULL, p_value, TERM_TAB);\n+\t\tanother = find_name(line, NULL, 1, TERM_TAB);\n \t\tif (!another || memcmp(another, name, len))\n \t\t\tdie(\"git-apply: bad git-diff - inconsistent %s filename on line %d\", oldnew, linenr);\n \t\tfree(another);\n@@ -427,28 +428,28 @@ static int gitdiff_newfile(const char *line, struct patch *patch)\n static int gitdiff_copysrc(const char *line, struct patch *patch)\n {\n \tpatch->is_copy = 1;\n-\tpatch->old_name = find_name(line, NULL, p_value-1, 0);\n+\tpatch->old_name = find_name(line, NULL, 0, 0);\n \treturn 0;\n }\n \n static int gitdiff_copydst(const char *line, struct patch *patch)\n {\n \tpatch->is_copy = 1;\n-\tpatch->new_name = find_name(line, NULL, p_value-1, 0);\n+\tpatch->new_name = find_name(line, NULL, 0, 0);\n \treturn 0;\n }\n \n static int gitdiff_renamesrc(const char *line, struct patch *patch)\n {\n \tpatch->is_rename = 1;\n-\tpatch->old_name = find_name(line, NULL, p_value-1, 0);\n+\tpatch->old_name = find_name(line, NULL, 0, 0);\n \treturn 0;\n }\n \n static int gitdiff_renamedst(const char *line, struct patch *patch)\n {\n \tpatch->is_rename = 1;\n-\tpatch->new_name = find_name(line, NULL, p_value-1, 0);\n+\tpatch->new_name = find_name(line, NULL, 0, 0);\n \treturn 0;\n }\n \n@@ -787,6 +788,7 @@ static int find_header(char *line, unsigned long size, int *hdrsize, struct patc\n {\n \tunsigned long offset, len;\n \n+\tpatch->is_toplevel_relative = 0;\n \tpatch->is_rename = patch->is_copy = 0;\n \tpatch->is_new = patch->is_delete = -1;\n \tpatch->old_mode = patch->new_mode = 0;\n@@ -831,6 +833,7 @@ static int find_header(char *line, unsigned long size, int *hdrsize, struct patc\n \t\t\t\t\tdie(\"git diff header lacks filename information (line %d)\", linenr);\n \t\t\t\tpatch->old_name = patch->new_name = patch->def_name;\n \t\t\t}\n+\t\t\tpatch->is_toplevel_relative = 1;\n \t\t\t*hdrsize = git_hdr_len;\n \t\t\treturn offset;\n \t\t}\n@@ -2499,6 +2502,12 @@ static int use_patch(struct patch *p)\n \t\t\treturn 0;\n \t\tx = x->next;\n \t}\n+\tif (0 < prefix_length) {\n+\t\tint pathlen = strlen(pathname);\n+\t\tif (pathlen <= prefix_length ||\n+\t\t memcmp(prefix, pathname, prefix_length))\n+\t\t\treturn 0;\n+\t}\n \treturn 1;\n }\n \n@@ -2513,7 +2522,7 @@ static void prefix_one(char **name)\n \n static void prefix_patches(struct patch *p)\n {\n-\tif (!prefix)\n+\tif (!prefix || p->is_toplevel_relative)\n \t\treturn;\n \tfor ( ; p; p = p->next) {\n \t\tif (p->new_name == p->old_name) {\ndiff --git a/t/t4119-apply-config.sh b/t/t4119-apply-config.sh\nindex f9b9425..32e0d71 100755\n--- a/t/t4119-apply-config.sh\n+++ b/t/t4119-apply-config.sh\n@@ -78,7 +78,7 @@ test_expect_success 'apply --whitespace=strip in subdir' '\n \tgit update-index --refresh &&\n \n \tcd sub &&\n-\tgit apply --whitespace=strip -p2 ../patch.file &&\n+\tgit apply --whitespace=strip ../patch.file &&\n \tif grep \" \" file1\n \tthen\n \t\techo \"Eh?\"\n@@ -101,7 +101,7 @@ test_expect_success 'apply --whitespace=strip from config in subdir' '\n \tgit update-index --refresh &&\n \n \tcd sub &&\n-\tgit apply -p2 ../patch.file &&\n+\tgit apply ../patch.file &&\n \tif grep \" \" file1\n \tthen\n \t\techo \"Eh?\"\n"},{"id":"35211","messageId":"7vtzxfm43t.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6861","inReplyTo":"7vy7mrm9ch.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] git-apply: guess correct -p value for non-git patches.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-22T00:24:22Z","receivedAt":"2007-02-22T00:24:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This enhances the third point in the previous commit. When\napplying a non-git patch that begins like this:\n\n\t--- 2.6.orig/mm/slab.c\n\t+++ 2.6/mm/slab.c\n\t@@ -N,M +L,K @@@\n\t...\n\nand if you are in 'mm' subdirectory, we notice that -p2 is the\nright option to use to apply the patch in file slab.c in the\ncurrent directory (i.e. mm/slab.c)\n\nThe guess function also knows about this pattern, where you\nwould need to use -p0 if applying from the top-level:\n\n\t--- mm/slab.c\n\t+++ mm/slab.c\n\t@@ -N,M +L,K @@@\n\t...\n\nSigned-off-by: Junio C Hamano \n---\n builtin-apply.c | 59 +++++++++++++++++++++++++++++++++++++++++++++-\n t/t4119-apply-config.sh | 56 +++++++++++++++++++++++++++++++++++++++++++-\n 2 files changed, 111 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin-apply.c b/builtin-apply.c\nindex 12f00e3..c7d4bdd 100644\n--- a/builtin-apply.c\n+++ b/builtin-apply.c\n@@ -28,6 +28,7 @@ static int newfd = -1;\n \n static int unidiff_zero;\n static int p_value = 1;\n+static int p_value_known;\n static int check_index;\n static int write_index;\n static int cached;\n@@ -312,11 +313,54 @@ static char *find_name(const char *line, char *def, int p_value, int terminate)\n \treturn name;\n }\n \n+static int count_slashes(const char *cp)\n+{\n+\tint cnt = 0;\n+\tchar ch;\n+\n+\twhile ((ch = *cp++))\n+\t\tif (ch == '/')\n+\t\t\tcnt++;\n+\treturn cnt;\n+}\n+\n+/*\n+ * Given the string after \"--- \" or \"+++ \", guess the appropriate\n+ * p_value for the given patch.\n+ */\n+static int guess_p_value(const char *nameline)\n+{\n+\tchar *name, *cp;\n+\tint val = -1;\n+\n+\tif (is_dev_null(nameline))\n+\t\treturn -1;\n+\tname = find_name(nameline, NULL, 0, TERM_SPACE | TERM_TAB);\n+\tif (!name)\n+\t\treturn -1;\n+\tcp = strchr(name, '/');\n+\tif (!cp)\n+\t\tval = 0;\n+\telse if (prefix) {\n+\t\t/*\n+\t\t * Does it begin with \"a/$our-prefix\" and such? Then this is\n+\t\t * very likely to apply to our directory.\n+\t\t */\n+\t\tif (!strncmp(name, prefix, prefix_length))\n+\t\t\tval = count_slashes(prefix);\n+\t\telse {\n+\t\t\tcp++;\n+\t\t\tif (!strncmp(cp, prefix, prefix_length))\n+\t\t\t\tval = count_slashes(prefix) + 1;\n+\t\t}\n+\t}\n+\tfree(name);\n+\treturn val;\n+}\n+\n /*\n * Get the name etc info from the --/+++ lines of a traditional patch header\n *\n- * NOTE! This hardcodes \"-p1\" behaviour in filename detection.\n- *\n * FIXME! The end-of-filename heuristics are kind of screwy. For existing\n * files, we can happily check the index for a match, but for creating a\n * new file we should try to match whatever \"patch\" does. I have no idea.\n@@ -327,6 +371,16 @@ static void parse_traditional_patch(const char *first, const char *second, struc\n \n \tfirst += 4;\t/* skip \"--- \" */\n \tsecond += 4;\t/* skip \"+++ \" */\n+\tif (!p_value_known) {\n+\t\tint p, q;\n+\t\tp = guess_p_value(first);\n+\t\tq = guess_p_value(second);\n+\t\tif (p < 0) p = q;\n+\t\tif (0 <= p && p == q) {\n+\t\t\tp_value = p;\n+\t\t\tp_value_known = 1;\n+\t\t}\n+\t}\n \tif (is_dev_null(first)) {\n \t\tpatch->is_new = 1;\n \t\tpatch->is_delete = 0;\n@@ -2656,6 +2710,7 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)\n \t\t}\n \t\tif (!strncmp(arg, \"-p\", 2)) {\n \t\t\tp_value = atoi(arg + 2);\n+\t\t\tp_value_known = 1;\n \t\t\tcontinue;\n \t\t}\n \t\tif (!strcmp(arg, \"--no-add\")) {\ndiff --git a/t/t4119-apply-config.sh b/t/t4119-apply-config.sh\nindex 32e0d71..55f4673 100755\n--- a/t/t4119-apply-config.sh\n+++ b/t/t4119-apply-config.sh\n@@ -19,7 +19,7 @@ test_expect_success setup '\n '\n \n # Also handcraft GNU diff output; note this has trailing whitespace.\n-cat >gpatch.file <<\\EOF\n+cat >gpatch.file <<\\EOF &&\n --- file1\t2007-02-21 01:04:24.000000000 -0800\n +++ file1+\t2007-02-21 01:07:44.000000000 -0800\n @@ -1 +1 @@\n@@ -27,6 +27,12 @@ cat >gpatch.file <<\\EOF\n +B \n EOF\n \n+sed -e 's|file1|sub/&|' gpatch.file >gpatch-sub.file &&\n+sed -e '\n+\t/^--- /s|file1|a/sub/&|\n+\t/^+++ /s|file1|b/sub/&|\n+' gpatch.file >gpatch-ab-sub.file &&\n+\n test_expect_success 'apply --whitespace=strip' '\n \n \trm -f sub/file1 &&\n@@ -124,7 +130,53 @@ test_expect_success 'same in subdir but with traditional patch input' '\n \tgit update-index --refresh &&\n \n \tcd sub &&\n-\tgit apply -p0 ../gpatch.file &&\n+\tgit apply ../gpatch.file &&\n+\tif grep \" \" file1\n+\tthen\n+\t\techo \"Eh?\"\n+\t\tfalse\n+\telif grep B file1\n+\tthen\n+\t\techo Happy\n+\telse\n+\t\techo \"Huh?\"\n+\t\tfalse\n+\tfi\n+'\n+\n+test_expect_success 'same but with traditional patch input of depth 1' '\n+\n+\tcd \"$D\" &&\n+\tgit config apply.whitespace strip &&\n+\trm -f sub/file1 &&\n+\tcp saved sub/file1 &&\n+\tgit update-index --refresh &&\n+\n+\tcd sub &&\n+\tgit apply ../gpatch-sub.file &&\n+\tif grep \" \" file1\n+\tthen\n+\t\techo \"Eh?\"\n+\t\tfalse\n+\telif grep B file1\n+\tthen\n+\t\techo Happy\n+\telse\n+\t\techo \"Huh?\"\n+\t\tfalse\n+\tfi\n+'\n+\n+test_expect_success 'same but with traditional patch input of depth 2' '\n+\n+\tcd \"$D\" &&\n+\tgit config apply.whitespace strip &&\n+\trm -f sub/file1 &&\n+\tcp saved sub/file1 &&\n+\tgit update-index --refresh &&\n+\n+\tcd sub &&\n+\tgit apply ../gpatch-ab-sub.file &&\n \tif grep \" \" file1\n \tthen\n \t\techo \"Eh?\"\n-- \n1.5.0.1.615.gfb51\n"}]}